November 2024 - Linux-stable-mirror

[PATCH 5.10.y 0/2] Fixed perf abort when taken branch stack sampling enabled

by Shuai Xue

On x86 platform, kernel v5.10.228, perf-report command aborts due to "free(): invalid pointer" when perf-record command is run with taken branch stack sampling enabled. This regression can be reproduced with the following steps: - sudo perf record -b - sudo perf report The root cause is that bi[i].to.ms.maps does not always point to thread->maps, which is a buffer dynamically allocated by maps_new(). Instead, it may point to &machine->kmaps, while kmaps is not a pointer but a variable. The original upstream commit c1149037f65b ("perf hist: Add missing puts to hist__account_cycles") worked well because machine->kmaps had been refactored to a pointer by the previous commit 1a97cee604dc ("perf maps: Use a pointer for kmaps"). The memory leak issue, which the reverted patch intended to fix, has been solved by commit cf96b8e45a9b ("perf session: Add missing evlist__delete when deleting a session"). The root cause is that the evlist is not being deleted on exit in perf-report, perf-script, and perf-data. Consequently, the reference count of the thread increased by thread__get() in hist_entry__init() is not decremented in hist_entry__delete(). As a result, thread->maps is not properly freed. To this end, - PATCH 1/2 reverts commit a83fc293acd5c5050a4828eced4a71d2b2fffdd3 to fix the abort regression. - PATCH 2/2 backports cf96b8e45a9b ("perf session: Add missing evlist__delete when deleting a session") to fix memory leak issue. Riccardo Mancini (1): perf session: Add missing evlist__delete when deleting a session Shuai Xue (1): Revert "perf hist: Add missing puts to hist__account_cycles" tools/perf/util/hist.c | 10 +++------- tools/perf/util/session.c | 5 ++++- 2 files changed, 7 insertions(+), 8 deletions(-) -- 2.39.3

11 months, 3 weeks

2
4
0 0

[PATCH] arm64: dts: allwinner: pinephone: Add mount matrix to accelerometer

by Dragan Simic

The way InvenSense MPU-6050 accelerometer is mounted on the user-facing side of the Pine64 PinePhone mainboard, which makes it rotated 90 degrees counter- clockwise, [1] requires the accelerometer's x- and y-axis to be swapped, and the direction of the accelerometer's y-axis to be inverted. Rectify this by adding a mount-matrix to the accelerometer definition in the Pine64 PinePhone dtsi file. [1] https://files.pine64.org/doc/PinePhone/PinePhone%20mainboard%20bottom%20pla… Fixes: 91f480d40942 ("arm64: dts: allwinner: Add initial support for Pine64 PinePhone") Cc: stable(a)vger.kernel.org Helped-by: Ondrej Jirman <megi(a)xff.cz> Helped-by: Andrey Skvortsov <andrej.skvortzov(a)gmail.com> Signed-off-by: Dragan Simic <dsimic(a)manjaro.org> --- Notes: See also the linux-sunxi thread [2] that has led to this patch, which provides a rather detailed analysis with additional details and pictures. This patch effectively replaces the patch submitted in that thread. [2] https://lore.kernel.org/linux-sunxi/20240916204521.2033218-1-andrej.skvortz… arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi index 6eab61a12cd8..b844759f52c0 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi @@ -212,6 +212,9 @@ accelerometer@68 { interrupts = <7 5 IRQ_TYPE_EDGE_RISING>; /* PH5 */ vdd-supply = <&reg_dldo1>; vddio-supply = <&reg_dldo1>; + mount-matrix = "0", "1", "0", + "-1", "0", "0", + "0", "0", "1"; }; };

11 months, 3 weeks

4
8
0 0

+ mm-readahead-fix-large-folio-support-in-async-readahead.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/readahead: fix large folio support in async readahead has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-readahead-fix-large-folio-support-in-async-readahead.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Yafang Shao <laoar.shao(a)gmail.com> Subject: mm/readahead: fix large folio support in async readahead Date: Fri, 8 Nov 2024 22:17:10 +0800 When testing large folio support with XFS on our servers, we observed that only a few large folios are mapped when reading large files via mmap. After a thorough analysis, I identified it was caused by the `/sys/block/*/queue/read_ahead_kb` setting. On our test servers, this parameter is set to 128KB. After I tune it to 2MB, the large folio can work as expected. However, I believe the large folio behavior should not be dependent on the value of read_ahead_kb. It would be more robust if the kernel can automatically adopt to it. With /sys/block/*/queue/read_ahead_kb set to 128KB and performing a sequential read on a 1GB file using MADV_HUGEPAGE, the differences in /proc/meminfo are as follows: - before this patch FileHugePages: 18432 kB FilePmdMapped: 4096 kB - after this patch FileHugePages: 1067008 kB FilePmdMapped: 1048576 kB This shows that after applying the patch, the entire 1GB file is mapped to huge pages. The stable list is CCed, as without this patch, large folios don't function optimally in the readahead path. It's worth noting that if read_ahead_kb is set to a larger value that isn't aligned with huge page sizes (e.g., 4MB + 128KB), it may still fail to map to hugepages. Link: https://lkml.kernel.org/r/20241108141710.9721-1-laoar.shao@gmail.com Fixes: 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file mappings") Suggested-by: Matthew Wilcox <willy(a)infradead.org> Signed-off-by: Yafang Shao <laoar.shao(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/readahead.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/readahead.c~mm-readahead-fix-large-folio-support-in-async-readahead +++ a/mm/readahead.c @@ -385,6 +385,8 @@ static unsigned long get_next_ra_size(st return 4 * cur; if (cur <= max / 2) return 2 * cur; + if (cur > max) + return cur; return max; } _ Patches currently in -mm which might be from laoar.shao(a)gmail.com are mm-readahead-fix-large-folio-support-in-async-readahead.patch

11 months, 3 weeks

1
0
0 0

+ nommu-pass-null-argument-to-vma_iter_prealloc.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: nommu: pass NULL argument to vma_iter_prealloc() has been added to the -mm mm-hotfixes-unstable branch. Its filename is nommu-pass-null-argument-to-vma_iter_prealloc.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hajime Tazaki <thehajime(a)gmail.com> Subject: nommu: pass NULL argument to vma_iter_prealloc() Date: Sat, 9 Nov 2024 07:28:34 +0900 When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call. Link: https://lkml.kernel.org/r/20241108222834.3625217-1-thehajime@gmail.com Fixes: b5df09226450 ("mm: set up vma iterator for vma_iter_prealloc() calls") Signed-off-by: Hajime Tazaki <thehajime(a)gmail.com> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)Oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/nommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/nommu.c~nommu-pass-null-argument-to-vma_iter_prealloc +++ a/mm/nommu.c @@ -573,7 +573,7 @@ static int delete_vma_from_mm(struct vm_ VMA_ITERATOR(vmi, vma->vm_mm, vma->vm_start); vma_iter_config(&vmi, vma->vm_start, vma->vm_end); - if (vma_iter_prealloc(&vmi, vma)) { + if (vma_iter_prealloc(&vmi, NULL)) { pr_warn("Allocation of vma tree for process %d failed\n", current->pid); return -ENOMEM; _ Patches currently in -mm which might be from thehajime(a)gmail.com are nommu-pass-null-argument-to-vma_iter_prealloc.patch

11 months, 3 weeks

1
0
0 0

[PATCH stable 6.11.y] netfs: reset subreq->iov_iter before netfs_clear_unread() tail clean

by Christian Ebner

Fixes file corruption issues when reading contents via ceph client. Call netfs_reset_subreq_iter() to align subreq->io_iter before calling netfs_clear_unread() to clear tail, as subreq->io_iter count and subreq->transferred might not be aligned after incomplete I/O, having the subreq's NETFS_SREQ_CLEAR_TAIL set. Based on ee4cdf7b ("netfs: Speed up buffered reading"), which introduces a fix for the issue in mainline. Fixes: 92b6cc5d ("netfs: Add iov_iters to (sub)requests to describe various buffers") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219237 Signed-off-by: Christian Ebner <c.ebner(a)proxmox.com> --- Sending this patch in an attempt to backport the fix introduced by commit ee4cdf7b ("netfs: Speed up buffered reading"), which however can not be cherry picked for older kernels, as the patch is not independent from other commits and touches a lot of unrelated (to the fix) code. fs/netfs/io.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/netfs/io.c b/fs/netfs/io.c index d6ada4eba744..500119285346 100644 --- a/fs/netfs/io.c +++ b/fs/netfs/io.c @@ -528,6 +528,7 @@ void netfs_subreq_terminated(struct netfs_io_subrequest *subreq, incomplete: if (test_bit(NETFS_SREQ_CLEAR_TAIL, &subreq->flags)) { + netfs_reset_subreq_iter(rreq, subreq); netfs_clear_unread(subreq); subreq->transferred = subreq->len; goto complete; -- 2.39.5

11 months, 3 weeks

2
5
0 0

[PATCH] spi: Fix deadlock when adding SPI controllers on SPI buses

by Hardik Gohil

From: Mark Brown <broonie(a)kernel.org> [ Upstream commit 6098475d4cb48d821bdf453c61118c56e26294f0 ] Currently we have a global spi_add_lock which we take when adding new devices so that we can check that we're not trying to reuse a chip select that's already controlled. This means that if the SPI device is itself a SPI controller and triggers the instantiation of further SPI devices we trigger a deadlock as we try to register and instantiate those devices while in the process of doing so for the parent controller and hence already holding the global spi_add_lock. Since we only care about concurrency within a single SPI bus move the lock to be per controller, avoiding the deadlock. This can be easily triggered in the case of spi-mux. Reported-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Hardik Gohil <hgohil(a)mvista.com> --- This fix was not backported to v5.4 and 5.10 Along with this fix please also apply this fix on top of this spi: fix use-after-free of the add_lock mutex commit 6c53b45c71b4920b5e62f0ea8079a1da382b9434 upstream. Commit 6098475d4cb4 ("spi: Fix deadlock when adding SPI controllers on SPI buses") introduced a per-controller mutex. But mutex_unlock() of said lock is called after the controller is already freed: drivers/spi/spi.c | 15 +++++---------- include/linux/spi/spi.h | 3 +++ 2 files changed, 8 insertions(+), 10 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 0f9410e..58f1947 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -472,12 +472,6 @@ static LIST_HEAD(spi_controller_list); */ static DEFINE_MUTEX(board_lock); -/* - * Prevents addition of devices with same chip select and - * addition of devices below an unregistering controller. - */ -static DEFINE_MUTEX(spi_add_lock); - /** * spi_alloc_device - Allocate a new SPI device * @ctlr: Controller to which device is connected @@ -580,7 +574,7 @@ int spi_add_device(struct spi_device *spi) * chipselect **BEFORE** we call setup(), else we'll trash * its configuration. Lock against concurrent add() calls. */ - mutex_lock(&spi_add_lock); + mutex_lock(&ctlr->add_lock); status = bus_for_each_dev(&spi_bus_type, NULL, spi, spi_dev_check); if (status) { @@ -624,7 +618,7 @@ int spi_add_device(struct spi_device *spi) } done: - mutex_unlock(&spi_add_lock); + mutex_unlock(&ctlr->add_lock); return status; } EXPORT_SYMBOL_GPL(spi_add_device); @@ -2512,6 +2506,7 @@ int spi_register_controller(struct spi_controller *ctlr) spin_lock_init(&ctlr->bus_lock_spinlock); mutex_init(&ctlr->bus_lock_mutex); mutex_init(&ctlr->io_mutex); + mutex_init(&ctlr->add_lock); ctlr->bus_lock_flag = 0; init_completion(&ctlr->xfer_completion); if (!ctlr->max_dma_len) @@ -2657,7 +2652,7 @@ void spi_unregister_controller(struct spi_controller *ctlr) /* Prevent addition of new devices, unregister existing ones */ if (IS_ENABLED(CONFIG_SPI_DYNAMIC)) - mutex_lock(&spi_add_lock); + mutex_lock(&ctlr->add_lock); device_for_each_child(&ctlr->dev, NULL, __unregister); @@ -2688,7 +2683,7 @@ void spi_unregister_controller(struct spi_controller *ctlr) mutex_unlock(&board_lock); if (IS_ENABLED(CONFIG_SPI_DYNAMIC)) - mutex_unlock(&spi_add_lock); + mutex_unlock(&ctlr->add_lock); } EXPORT_SYMBOL_GPL(spi_unregister_controller); diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index ca39b33..1b9cb90 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -483,6 +483,9 @@ struct spi_controller { /* I/O mutex */ struct mutex io_mutex; + /* Used to avoid adding the same CS twice */ + struct mutex add_lock; + /* lock and mutex for SPI bus locking */ spinlock_t bus_lock_spinlock; struct mutex bus_lock_mutex; -- 2.7.4

11 months, 3 weeks

2
1
0 0

[PATCH] drm/rockchip: cdn-dp: Use drm_connector_helper_hpd_irq_event()

by Thomas Zimmermann

The code for detecting and updating the connector status in cdn_dp_pd_event_work() has a number of problems. - It does not aquire the locks to call the detect helper and update the connector status. These are struct drm_mode_config.connection_mutex and struct drm_mode_config.mutex. - It does not use drm_helper_probe_detect(), which helps with the details of locking and detection. - It uses the connector's status field to determine a change to the connector status. The epoch_counter field is the correct one. The field signals a change even if the connector status' value did not change. Replace the code with a call to drm_connector_helper_hpd_irq_event(), which fixes all these problems. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: 81632df69772 ("drm/rockchip: cdn-dp: do not use drm_helper_hpd_irq_event") Cc: Chris Zhong <zyw(a)rock-chips.com> Cc: Guenter Roeck <groeck(a)chromium.org> Cc: Sandy Huang <hjc(a)rock-chips.com> Cc: "Heiko Stübner" <heiko(a)sntech.de> Cc: Andy Yan <andy.yan(a)rock-chips.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-rockchip(a)lists.infradead.org Cc: <stable(a)vger.kernel.org> # v4.11+ --- drivers/gpu/drm/rockchip/cdn-dp-core.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c index b04538907f95..f576b1aa86d1 100644 --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c @@ -947,9 +947,6 @@ static void cdn_dp_pd_event_work(struct work_struct *work) { struct cdn_dp_device *dp = container_of(work, struct cdn_dp_device, event_work); - struct drm_connector *connector = &dp->connector; - enum drm_connector_status old_status; - int ret; mutex_lock(&dp->lock); @@ -1009,11 +1006,7 @@ static void cdn_dp_pd_event_work(struct work_struct *work) out: mutex_unlock(&dp->lock); - - old_status = connector->status; - connector->status = connector->funcs->detect(connector, false); - if (old_status != connector->status) - drm_kms_helper_hotplug_event(dp->drm_dev); + drm_connector_helper_hpd_irq_event(&dp->connector); } static int cdn_dp_pd_event(struct notifier_block *nb, -- 2.47.0

11 months, 3 weeks

2
1
0 0

[PATCH 6.1] Revert "wifi: mac80211: fix RCU list iterations"

by Fedor Pchelkin

This reverts commit b0b2dc1eaa7ec509e07a78c9974097168ae565b7 which is commit ac35180032fbc5d80b29af00ba4881815ceefcb6 upstream. The reverted commit is based heavily on wiphy locking changes made by the "wifi: cfg80211/mac80211: locking cleanups" series [1] introduced since 6.7 kernel and not supposed to be backported to old stable branches. It breaks locking rules in the context of old stables leading e.g. to the following lockdep splat there - ieee80211_get_max_required_bw() is actually called under RCU reader lock in 6.1/6.6, not the wiphy mutex. WARNING: CPU: 3 PID: 8711 at net/mac80211/chan.c:248 ieee80211_get_max_required_bw+0x423/0x4e0 net/mac80211/chan.c:248 Modules linked in: CPU: 3 PID: 8711 Comm: kworker/u8:6 Not tainted 6.1.113-syzkaller-00105-g9859ec205cfa #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: phy155 ieee80211_iface_work RIP: 0010:ieee80211_get_max_required_bw+0x423/0x4e0 net/mac80211/chan.c:248 Call Trace: <TASK> ieee80211_get_chanctx_vif_max_required_bw net/mac80211/chan.c:294 [inline] ieee80211_get_chanctx_max_required_bw net/mac80211/chan.c:336 [inline] _ieee80211_recalc_chanctx_min_def+0x5e6/0xf30 net/mac80211/chan.c:381 ieee80211_recalc_chanctx_min_def+0x21/0x80 net/mac80211/chan.c:462 ieee80211_recalc_min_chandef+0x17a/0x590 net/mac80211/util.c:2908 sta_info_move_state+0x748/0x8c0 net/mac80211/sta_info.c:2301 ieee80211_assoc_success net/mac80211/mlme.c:5001 [inline] ieee80211_rx_mgmt_assoc_resp.cold+0x1335/0x69ec net/mac80211/mlme.c:5201 ieee80211_sta_rx_queued_mgmt+0x40f/0x2270 net/mac80211/mlme.c:5831 ieee80211_iface_process_skb net/mac80211/iface.c:1665 [inline] ieee80211_iface_work+0xa31/0xd30 net/mac80211/iface.c:1722 process_one_work+0xa72/0x1590 kernel/workqueue.c:2292 worker_thread+0x632/0x1240 kernel/workqueue.c:2439 kthread+0x2e1/0x3a0 kernel/kthread.c:376 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:295 [1]: https://lore.kernel.org/linux-wireless/20230828115927.116700-41-johannes@si… Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Cc: Johannes Berg <johannes(a)sipsolutions.net> Cc: Miriam Rachel Korenblit <miriam.rachel.korenblit(a)intel.com> Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- net/mac80211/chan.c | 4 +--- net/mac80211/mlme.c | 2 +- net/mac80211/scan.c | 2 +- net/mac80211/util.c | 4 +--- 4 files changed, 4 insertions(+), 8 deletions(-) diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c index 807bea1a7d3c..f07e34bed8f3 100644 --- a/net/mac80211/chan.c +++ b/net/mac80211/chan.c @@ -245,9 +245,7 @@ ieee80211_get_max_required_bw(struct ieee80211_sub_if_data *sdata, enum nl80211_chan_width max_bw = NL80211_CHAN_WIDTH_20_NOHT; struct sta_info *sta; - lockdep_assert_wiphy(sdata->local->hw.wiphy); - - list_for_each_entry(sta, &sdata->local->sta_list, list) { + list_for_each_entry_rcu(sta, &sdata->local->sta_list, list) { if (sdata != sta->sdata && !(sta->sdata->bss && sta->sdata->bss == sdata->bss)) continue; diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index ee9ec74b9553..9a5530ca2f6b 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -660,7 +660,7 @@ static bool ieee80211_add_vht_ie(struct ieee80211_sub_if_data *sdata, bool disable_mu_mimo = false; struct ieee80211_sub_if_data *other; - list_for_each_entry(other, &local->interfaces, list) { + list_for_each_entry_rcu(other, &local->interfaces, list) { if (other->vif.bss_conf.mu_mimo_owner) { disable_mu_mimo = true; break; diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c index edbf468e0bea..f1147d156c1f 100644 --- a/net/mac80211/scan.c +++ b/net/mac80211/scan.c @@ -501,7 +501,7 @@ static void __ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted) * the scan was in progress; if there was none this will * just be a no-op for the particular interface. */ - list_for_each_entry(sdata, &local->interfaces, list) { + list_for_each_entry_rcu(sdata, &local->interfaces, list) { if (ieee80211_sdata_running(sdata)) ieee80211_queue_work(&sdata->local->hw, &sdata->work); } diff --git a/net/mac80211/util.c b/net/mac80211/util.c index 3fe15089b24f..738f1f139a90 100644 --- a/net/mac80211/util.c +++ b/net/mac80211/util.c @@ -767,9 +767,7 @@ static void __iterate_interfaces(struct ieee80211_local *local, struct ieee80211_sub_if_data *sdata; bool active_only = iter_flags & IEEE80211_IFACE_ITER_ACTIVE; - list_for_each_entry_rcu(sdata, &local->interfaces, list, - lockdep_is_held(&local->iflist_mtx) || - lockdep_is_held(&local->hw.wiphy->mtx)) { + list_for_each_entry_rcu(sdata, &local->interfaces, list) { switch (sdata->vif.type) { case NL80211_IFTYPE_MONITOR: if (!(sdata->u.mntr.flags & MONITOR_FLAG_ACTIVE)) -- 2.39.5

11 months, 3 weeks

1
0
0 0

[PATCH 6.6] Revert "wifi: mac80211: fix RCU list iterations"

by Fedor Pchelkin

This reverts commit f37319609335d3eb2f7edfec4bad7996668a4d29 which is commit ac35180032fbc5d80b29af00ba4881815ceefcb6 upstream. The reverted commit is based heavily on wiphy locking changes made by the "wifi: cfg80211/mac80211: locking cleanups" series [1] introduced since 6.7 kernel and not supposed to be backported to old stable branches. It breaks locking rules in the context of old stables leading e.g. to the following lockdep splat there - ieee80211_get_max_required_bw() is actually called under RCU reader lock in 6.1/6.6, not the wiphy mutex. WARNING: CPU: 3 PID: 8711 at net/mac80211/chan.c:248 ieee80211_get_max_required_bw+0x423/0x4e0 net/mac80211/chan.c:248 Modules linked in: CPU: 3 PID: 8711 Comm: kworker/u8:6 Not tainted 6.1.113-syzkaller-00105-g9859ec205cfa #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: phy155 ieee80211_iface_work RIP: 0010:ieee80211_get_max_required_bw+0x423/0x4e0 net/mac80211/chan.c:248 Call Trace: <TASK> ieee80211_get_chanctx_vif_max_required_bw net/mac80211/chan.c:294 [inline] ieee80211_get_chanctx_max_required_bw net/mac80211/chan.c:336 [inline] _ieee80211_recalc_chanctx_min_def+0x5e6/0xf30 net/mac80211/chan.c:381 ieee80211_recalc_chanctx_min_def+0x21/0x80 net/mac80211/chan.c:462 ieee80211_recalc_min_chandef+0x17a/0x590 net/mac80211/util.c:2908 sta_info_move_state+0x748/0x8c0 net/mac80211/sta_info.c:2301 ieee80211_assoc_success net/mac80211/mlme.c:5001 [inline] ieee80211_rx_mgmt_assoc_resp.cold+0x1335/0x69ec net/mac80211/mlme.c:5201 ieee80211_sta_rx_queued_mgmt+0x40f/0x2270 net/mac80211/mlme.c:5831 ieee80211_iface_process_skb net/mac80211/iface.c:1665 [inline] ieee80211_iface_work+0xa31/0xd30 net/mac80211/iface.c:1722 process_one_work+0xa72/0x1590 kernel/workqueue.c:2292 worker_thread+0x632/0x1240 kernel/workqueue.c:2439 kthread+0x2e1/0x3a0 kernel/kthread.c:376 ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:295 [1]: https://lore.kernel.org/linux-wireless/20230828115927.116700-41-johannes@si… Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Cc: Johannes Berg <johannes(a)sipsolutions.net> Cc: Miriam Rachel Korenblit <miriam.rachel.korenblit(a)intel.com> Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- net/mac80211/chan.c | 4 +--- net/mac80211/mlme.c | 2 +- net/mac80211/scan.c | 2 +- net/mac80211/util.c | 4 +--- 4 files changed, 4 insertions(+), 8 deletions(-) diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c index c09aed6a3cfc..68952752b599 100644 --- a/net/mac80211/chan.c +++ b/net/mac80211/chan.c @@ -245,9 +245,7 @@ ieee80211_get_max_required_bw(struct ieee80211_sub_if_data *sdata, enum nl80211_chan_width max_bw = NL80211_CHAN_WIDTH_20_NOHT; struct sta_info *sta; - lockdep_assert_wiphy(sdata->local->hw.wiphy); - - list_for_each_entry(sta, &sdata->local->sta_list, list) { + list_for_each_entry_rcu(sta, &sdata->local->sta_list, list) { if (sdata != sta->sdata && !(sta->sdata->bss && sta->sdata->bss == sdata->bss)) continue; diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index b14c809bcdea..42e2c84ed248 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -732,7 +732,7 @@ static bool ieee80211_add_vht_ie(struct ieee80211_sub_if_data *sdata, bool disable_mu_mimo = false; struct ieee80211_sub_if_data *other; - list_for_each_entry(other, &local->interfaces, list) { + list_for_each_entry_rcu(other, &local->interfaces, list) { if (other->vif.bss_conf.mu_mimo_owner) { disable_mu_mimo = true; break; diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c index d4a032f34577..1726e3221d3c 100644 --- a/net/mac80211/scan.c +++ b/net/mac80211/scan.c @@ -490,7 +490,7 @@ static void __ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted) * the scan was in progress; if there was none this will * just be a no-op for the particular interface. */ - list_for_each_entry(sdata, &local->interfaces, list) { + list_for_each_entry_rcu(sdata, &local->interfaces, list) { if (ieee80211_sdata_running(sdata)) wiphy_work_queue(sdata->local->hw.wiphy, &sdata->work); } diff --git a/net/mac80211/util.c b/net/mac80211/util.c index 02b5aaad2a15..d682c32821a1 100644 --- a/net/mac80211/util.c +++ b/net/mac80211/util.c @@ -745,9 +745,7 @@ static void __iterate_interfaces(struct ieee80211_local *local, struct ieee80211_sub_if_data *sdata; bool active_only = iter_flags & IEEE80211_IFACE_ITER_ACTIVE; - list_for_each_entry_rcu(sdata, &local->interfaces, list, - lockdep_is_held(&local->iflist_mtx) || - lockdep_is_held(&local->hw.wiphy->mtx)) { + list_for_each_entry_rcu(sdata, &local->interfaces, list) { switch (sdata->vif.type) { case NL80211_IFTYPE_MONITOR: if (!(sdata->u.mntr.flags & MONITOR_FLAG_ACTIVE)) -- 2.39.5

11 months, 3 weeks

1
0
0 0

AMD PMF on 6.11.y

by Mario Limonciello

Hi, 6.11 already supports most functionality of AMD family 0x1a model 0x60, but the amd-pmf driver doesn't load due to a missing device ID. The device ID was added in 6.12 with: commit 8ca8d07857c69 ("platform/x86/amd/pmf: Add SMU metrics table support for 1Ah family 60h model") Can this please come back to 6.11.y to enable it more widely? Thanks!

11 months, 3 weeks

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror November 2024