June 2025 - Linux-stable-mirror

[PATCH v3 0/3] pwm: axi-pwmgen: add external clock

by David Lechner

When we created the driver for the AXI PWMGEN IP block, we overlooked the fact that it can optionally be configured to use an external clock in addition to the AXI bus clock. This is easy to miss in testing because the bus clock is always on because it is driving other peripherals as well. Up to now, users were specifying the external clock if there was one and the AXI bus clock otherwise. But the proper way to do this is to would be to always specify the bus clock and only specify the external clock if the IP block has been configured to use it. To fix this, we add clock-names to the devicetree bindings and change clocks to allow 1 or 2 clocks. --- Changes in v3: - Fixed clock-names DT property restrictions (was failing dt_binding_check) - Added Cc: stable - Picked up trailers - Link to v2: https://lore.kernel.org/r/20250522-pwm-axi-pwmgen-add-external-clock-v2-0-0… Changes in v2: - Consider this a fix rather than a new feature. - Make clock-names required. - Simplify the logic in the pwm driver to avoid needing to test if clock-names is present in old dtbs that used the broken binding. - Link to v1: https://lore.kernel.org/r/20250520-pwm-axi-pwmgen-add-external-clock-v1-0-6… --- David Lechner (3): dt-bindings: pwm: adi,axi-pwmgen: update documentation link dt-bindings: pwm: adi,axi-pwmgen: fix clocks pwm: axi-pwmgen: fix missing separate external clock .../devicetree/bindings/pwm/adi,axi-pwmgen.yaml | 15 +++++++++++--- drivers/pwm/pwm-axi-pwmgen.c | 23 +++++++++++++++++++--- 2 files changed, 32 insertions(+), 6 deletions(-) --- base-commit: 484803582c77061b470ac64a634f25f89715be3f change-id: 20250515-pwm-axi-pwmgen-add-external-clock-0364fbdf809b Best regards, -- David Lechner <dlechner(a)baylibre.com>

5 days

3
4
0 0

[PATCH 5.4.y 0/1] Manual Backport of 099606a7b2d5 to 5.4

by Harshvardhan Jha

The patch 099606a7b2d5 didn't cleanly apply to 5.4 due to the significant difference in codebases. I've tried to manually bring it back to 5.4 via some minor conflict resolution but also invoking the newly introduced API using inverted logic as the conditionals present in 5.4 are the opposite of those in 6.1 xen/swiotlib. Harshvardhan Jha (1): xen/swiotlb: relax alignment requirements drivers/xen/swiotlb-xen.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) -- 2.47.1

5 days, 1 hour

2
2
0 0

[PATCH 5.10.y 0/1] Manual Backport of 099606a7b2d5 to 5.10

by Harshvardhan Jha

The patch 099606a7b2d5 didn't cleanly apply to 5.10 due to the significant difference in codebases. I've tried to manually bring it back to 5.10 via some minor conflict resolution but also invoking the newly introduced API using inverted logic as the conditionals present in 5.10 are the opposite of those in 6.1 xen/swiotlib. Harshvardhan Jha (1): xen/swiotlb: relax alignment requirements drivers/xen/swiotlb-xen.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) -- 2.47.1

5 days, 1 hour

2
2
0 0

[PATCH 5.10/5.15] perf/arm-cmn: Initialise cmn->cpu earlier

by Robin Murphy

commit 597704e201068db3d104de3c7a4d447ff8209127 upstream. For all the complexity of handling affinity for CPU hotplug, what we've apparently managed to overlook is that arm_cmn_init_irqs() has in fact always been setting the *initial* affinity of all IRQs to CPU 0, not the CPU we subsequently choose for event scheduling. Oh dear. Cc: stable(a)vger.kernel.org Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver") Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> Reviewed-by: Ilkka Koskinen <ilkka(a)os.amperecomputing.com> Link: https://lore.kernel.org/r/b12fccba6b5b4d2674944f59e4daad91cd63420b.17470699… Signed-off-by: Will Deacon <will(a)kernel.org> [ backport past NUMA changes in 5.17 ] Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> --- drivers/perf/arm-cmn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c index e2a055ba0b7a..cabeff8c944b 100644 --- a/drivers/perf/arm-cmn.c +++ b/drivers/perf/arm-cmn.c @@ -1512,6 +1512,7 @@ static int arm_cmn_probe(struct platform_device *pdev) return -ENOMEM; cmn->dev = &pdev->dev; + cmn->cpu = raw_smp_processor_id(); platform_set_drvdata(pdev, cmn); if (has_acpi_companion(cmn->dev)) @@ -1533,7 +1534,6 @@ static int arm_cmn_probe(struct platform_device *pdev) if (err) return err; - cmn->cpu = raw_smp_processor_id(); cmn->pmu = (struct pmu) { .module = THIS_MODULE, .attr_groups = arm_cmn_attr_groups, -- 2.39.2.101.g768bb238c484.dirty

5 days, 1 hour

2
1
0 0

[PATCH] drm/etnaviv: Protect the scheduler's pending list with its lock

by Maíra Canal

Commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active") ensured that active jobs are returned to the pending list when extending the timeout. However, it didn't use the pending list's lock to manipulate the list, which causes a race condition as the scheduler's workqueues are running. Hold the lock while manipulating the scheduler's pending list to prevent a race. Cc: stable(a)vger.kernel.org Fixes: 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active") Signed-off-by: Maíra Canal <mcanal(a)igalia.com> --- Hi, I'm proposing this workaround patch to address the race-condition caused by manipulating the pending list without using its lock. Although I understand this isn't a complete solution (see [1]), it's not reasonable to backport the new DRM stat series [2] to the stable branches. Therefore, I believe the best solution is backporting this fix to the stable branches, which will fix the race and will keep adding the job back to the pending list (which will avoid most memory leaks). [1] https://lore.kernel.org/dri-devel/bcc0ed477f8a6f3bb06665b1756bcb98fb7af871.… [2] https://lore.kernel.org/dri-devel/20250530-sched-skip-reset-v2-0-c40a8d2d8d… Best Regards, - Maíra --- drivers/gpu/drm/etnaviv/etnaviv_sched.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c b/drivers/gpu/drm/etnaviv/etnaviv_sched.c index 76a3a3e517d8..71e2e6b9d713 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c @@ -35,6 +35,7 @@ static enum drm_gpu_sched_stat etnaviv_sched_timedout_job(struct drm_sched_job *sched_job) { struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job); + struct drm_gpu_scheduler *sched = sched_job->sched; struct etnaviv_gpu *gpu = submit->gpu; u32 dma_addr, primid = 0; int change; @@ -89,7 +90,9 @@ static enum drm_gpu_sched_stat etnaviv_sched_timedout_job(struct drm_sched_job return DRM_GPU_SCHED_STAT_NOMINAL; out_no_timeout: - list_add(&sched_job->list, &sched_job->sched->pending_list); + spin_lock(&sched->job_list_lock); + list_add(&sched_job->list, &sched->pending_list); + spin_unlock(&sched->job_list_lock); return DRM_GPU_SCHED_STAT_NOMINAL; } -- 2.49.0

5 days, 1 hour

2
1
0 0

[PATCH 5.10] ibmvnic: Add tx check to prevent skb leak

by Denis Arefev

From: Nick Child <nnac123(a)linux.ibm.com> commit 0983d288caf984de0202c66641577b739caad561 upstream. Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] consumer_index^ tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems. Signed-off-by: Nick Child <nnac123(a)linux.ibm.com> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-41066 Link: https://nvd.nist.gov/vuln/detail/CVE-2024-41066 --- drivers/net/ethernet/ibm/ibmvnic.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c index 84da6ccaf339..e63220ebb2ea 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -1625,6 +1625,18 @@ static netdev_tx_t ibmvnic_xmit(struct sk_buff *skb, struct net_device *netdev) (tx_pool->consumer_index + 1) % tx_pool->num_buffers; tx_buff = &tx_pool->tx_buff[index]; + + /* Sanity checks on our free map to make sure it points to an index + * that is not being occupied by another skb. If skb memory is + * not freed then we see congestion control kick in and halt tx. + */ + if (unlikely(tx_buff->skb)) { + dev_warn_ratelimited(dev, "TX free map points to untracked skb (%s %d idx=%d)\n", + skb_is_gso(skb) ? "tso_pool" : "tx_pool", + queue_num, index); + dev_kfree_skb_any(tx_buff->skb); + } + tx_buff->skb = skb; tx_buff->data_dma[0] = data_dma_addr; tx_buff->data_len[0] = skb->len; -- 2.43.0

5 days, 2 hours

1
0
0 0

[PATCH] iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush

by Sean Nyekjaer

fxls8962af_fifo_flush() uses indio_dev->active_scan_mask (with iio_for_each_active_channel()) without making sure the indio_dev stays in buffer mode. There is a race if indio_dev exits buffer mode in the middle of the interrupt that flushes the fifo. Fix this by calling iio_device_claim_buffer_mode() to ensure indio_dev can't exit buffer mode during the flush. Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read [...] _find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290 fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178 fxls8962af_interrupt from irq_thread_fn+0x1c/0x7c irq_thread_fn from irq_thread+0x110/0x1f4 irq_thread from kthread+0xe0/0xfc kthread from ret_from_fork+0x14/0x2c Fixes: 79e3a5bdd9ef ("iio: accel: fxls8962af: add hw buffered sampling") Cc: stable(a)vger.kernel.org Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> --- drivers/iio/accel/fxls8962af-core.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/iio/accel/fxls8962af-core.c b/drivers/iio/accel/fxls8962af-core.c index 6d23da3e7aa22c61f2d9348bb91d70cc5719a732..7db83ebeea823173d79bf8ff484add16f575edfc 100644 --- a/drivers/iio/accel/fxls8962af-core.c +++ b/drivers/iio/accel/fxls8962af-core.c @@ -973,6 +973,9 @@ static int fxls8962af_fifo_flush(struct iio_dev *indio_dev) if (ret) return ret; + if (iio_device_claim_buffer_mode(indio_dev) < 0) + return 0; + /* Demux hw FIFO into kfifo. */ for (i = 0; i < count; i++) { int j, bit; @@ -989,6 +992,8 @@ static int fxls8962af_fifo_flush(struct iio_dev *indio_dev) tstamp += sample_period; } + iio_device_release_buffer_mode(indio_dev); + return count; } --- base-commit: 5c3fcb36c92443a9a037683626a2e43d8825f783 change-id: 20250524-fxlsrace-f4d20e29fb29 Best regards, -- Sean Nyekjaer <sean(a)geanix.com>

5 days, 2 hours

4
9
0 0

[PATCH 5.10] xfs: add bounds checking to xlog_recover_process_data

by Denis Arefev

From: lei lu <llfamsec(a)gmail.com> commit fb63435b7c7dc112b1ae1baea5486e0a6e27b196 upstream. There is a lack of verification of the space occupied by fixed members of xlog_op_header in the xlog_recover_process_data. We can create a crafted image to trigger an out of bounds read by following these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tail_blk and head_blk are the same, which will result in the inability to enter xlog_recover_process_data 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlog_op_header entries only 1 byte away from xlog_rec_header->h_size 5) xlog_rec_header->h_num_logops++ 6) Modify xlog_rec_header->h_crc Fix: Add a check to make sure there is sufficient space to access fixed members of xlog_op_header. Signed-off-by: lei lu <llfamsec(a)gmail.com> Reviewed-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-41014 Link: https://nvd.nist.gov/vuln/detail/cve-2024-41014 --- fs/xfs/xfs_log_recover.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c index e61f28ce3e44..eafe76f304ef 100644 --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -2419,7 +2419,10 @@ xlog_recover_process_data( ohead = (struct xlog_op_header *)dp; dp += sizeof(*ohead); - ASSERT(dp <= end); + if (dp > end) { + xfs_warn(log->l_mp, "%s: op header overrun", __func__); + return -EFSCORRUPTED; + } /* errors will abort recovery */ error = xlog_recover_process_ophdr(log, rhash, rhead, ohead, -- 2.43.0

5 days, 3 hours

1
0
0 0

Please pick 0c8e9c148e29 and da33e87bd2bf for linux-6.15.y

by Robin Murphy

Hi Greg, Sasha, Please could you pick these commits for linux-6.15.y: 0c8e9c148e29 ("iommu: Avoid introducing more races") da33e87bd2bf ("iommu: Handle yet another race around registration") which in hindsight should ideally have been merged as fixes during the cycle, but for various reasons were queued as 6.16 material at the time. Thanks, Robin.

5 days, 5 hours

2
1
0 0

Re: [PATCH v5] virtio_blk: Fix disk deletion hang on device surprise removal

by ALOK TIWARI

On 02-06-2025 08:14, Parav Pandit wrote: > When the PCI device is surprise removed, requests may not complete > the device as the VQ is marked as broken. Due to this, the disk > deletion hangs. > > Fix it by aborting the requests when the VQ is broken. > > With this fix now fio completes swiftly. > An alternative of IO timeout has been considered, however > when the driver knows about unresponsive block device, swiftly clearing > them enables users and upper layers to react quickly. > > Verified with multiple device unplug iterations with pending requests in > virtio used ring and some pending with the device. > > Fixes: 43bb40c5b926 ("virtio_pci: Support surprise removal of virtio pci device") > Cc:stable@vger.kernel.org > Reported-by: Li RongQing<lirongqing(a)baidu.com> > Closes:https://urldefense.com/v3/__https://lore.kernel.org/virtualization/ > c45dd68698cd47238c55fb73ca9b4741(a)baidu.com/__;!!ACWV5N9M2RV99hQ! > OKusQ3sGH7nkVTy9MUDtaIS17UDtjabP3Lby9jTBdT3Ur38XLl2_DOFo0eVzx_dNeh16lD3Ss6ItE9eG$ > Reviewed-by: Max Gurtovoy<mgurtovoy(a)nvidia.com> > Reviewed-by: Israel Rukshin<israelr(a)nvidia.com> > Signed-off-by: Parav Pandit<parav(a)nvidia.com> look good to me. Reviewed-by: Alok Tiwari <alok.a.tiwari(a)oracle.com> Thanks, Alok

5 days, 5 hours

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2025