June 2025 - Linux-stable-mirror

by Alan Ye

Hi The IPQ50xx chip integrates only a 2x2 2.4GHz Wi-Fi module. Through the high-performance NSS core and PCIe expansion and integration the application range of the IPQ50xx chip ranges from Wi-Fi mesh node to Enterprise AP. OEM manufacturers can think in a unified way when doing circuit design and PCB layout, and the same packaging can really save designers a lot of trouble. .# Part Number Manufacturer Date Code Quantity Unit Price Lead Time Condition (PCS) USD/Each one 1 IPQ-5018-0-MRQFN232-TR-01-0 QUALCOMM 2022+ 30000pcs US$3.50/pcs 7days New & original - stock 2 QCN-6102-0-DRQFN116-TR-01-1 QUALCOMM 2022+ 30000pcs US$2.50/pcs 3 QCN-9024-0-MSP234-TR-01-0 QUALCOMM 2022+ 5000pcs US$3.50/pcs 4 QCN-6112-0-DRQFN116-TR-01-0 QUALCOMM 2023+ 15000pcs US$2.70/pcs 5 QCA-8337-AL3C-R QUALCOMM 2023+ 20000pcs US$1.30/pcs The above are our company's current inventory, all of which are genuine and original packaging. If you need anything, please feel free to contact me, thank you Best Regards Maintain your product-savvy edge with . Stay Updated on News If you prefer to exit, choose Review Communication Options.

3 months, 4 weeks

1
0
0 0

[merged] fs-dax-fix-dont-skip-locked-entries-when-scanning-entries.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: fs/dax: fix "don't skip locked entries when scanning entries" has been removed from the -mm tree. Its filename was fs-dax-fix-dont-skip-locked-entries-when-scanning-entries.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Alistair Popple <apopple(a)nvidia.com> Subject: fs/dax: fix "don't skip locked entries when scanning entries" Date: Fri, 23 May 2025 14:37:49 +1000 Commit 6be3e21d25ca ("fs/dax: don't skip locked entries when scanning entries") introduced a new function, wait_entry_unlocked_exclusive(), which waits for the current entry to become unlocked without advancing the XArray iterator state. Waiting for the entry to become unlocked requires dropping the XArray lock. This requires calling xas_pause() prior to dropping the lock which leaves the xas in a suitable state for the next iteration. However this has the side-effect of advancing the xas state to the next index. Normally this isn't an issue because xas_for_each() contains code to detect this state and thus avoid advancing the index a second time on the next loop iteration. However both callers of and wait_entry_unlocked_exclusive() itself subsequently use the xas state to reload the entry. As xas_pause() updated the state to the next index this will cause the current entry which is being waited on to be skipped. This caused the following warning to fire intermittently when running xftest generic/068 on an XFS filesystem with FS DAX enabled: [ 35.067397] ------------[ cut here ]------------ [ 35.068229] WARNING: CPU: 21 PID: 1640 at mm/truncate.c:89 truncate_folio_batch_exceptionals+0xd8/0x1e0 [ 35.069717] Modules linked in: nd_pmem dax_pmem nd_btt nd_e820 libnvdimm [ 35.071006] CPU: 21 UID: 0 PID: 1640 Comm: fstest Not tainted 6.15.0-rc7+ #77 PREEMPT(voluntary) [ 35.072613] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/204 [ 35.074845] RIP: 0010:truncate_folio_batch_exceptionals+0xd8/0x1e0 [ 35.075962] Code: a1 00 00 00 f6 47 0d 20 0f 84 97 00 00 00 4c 63 e8 41 39 c4 7f 0b eb 61 49 83 c5 01 45 39 ec 7e 58 42 f68 [ 35.079522] RSP: 0018:ffffb04e426c7850 EFLAGS: 00010202 [ 35.080359] RAX: 0000000000000000 RBX: ffff9d21e3481908 RCX: ffffb04e426c77f4 [ 35.081477] RDX: ffffb04e426c79e8 RSI: ffffb04e426c79e0 RDI: ffff9d21e34816e8 [ 35.082590] RBP: ffffb04e426c79e0 R08: 0000000000000001 R09: 0000000000000003 [ 35.083733] R10: 0000000000000000 R11: 822b53c0f7a49868 R12: 000000000000001f [ 35.084850] R13: 0000000000000000 R14: ffffb04e426c78e8 R15: fffffffffffffffe [ 35.085953] FS: 00007f9134c87740(0000) GS:ffff9d22abba0000(0000) knlGS:0000000000000000 [ 35.087346] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 35.088244] CR2: 00007f9134c86000 CR3: 000000040afff000 CR4: 00000000000006f0 [ 35.089354] Call Trace: [ 35.089749] <TASK> [ 35.090168] truncate_inode_pages_range+0xfc/0x4d0 [ 35.091078] truncate_pagecache+0x47/0x60 [ 35.091735] xfs_setattr_size+0xc7/0x3e0 [ 35.092648] xfs_vn_setattr+0x1ea/0x270 [ 35.093437] notify_change+0x1f4/0x510 [ 35.094219] ? do_truncate+0x97/0xe0 [ 35.094879] do_truncate+0x97/0xe0 [ 35.095640] path_openat+0xabd/0xca0 [ 35.096278] do_filp_open+0xd7/0x190 [ 35.096860] do_sys_openat2+0x8a/0xe0 [ 35.097459] __x64_sys_openat+0x6d/0xa0 [ 35.098076] do_syscall_64+0xbb/0x1d0 [ 35.098647] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 35.099444] RIP: 0033:0x7f9134d81fc1 [ 35.100033] Code: 75 57 89 f0 25 00 00 41 00 3d 00 00 41 00 74 49 80 3d 2a 26 0e 00 00 74 6d 89 da 48 89 ee bf 9c ff ff ff5 [ 35.102993] RSP: 002b:00007ffcd41e0d10 EFLAGS: 00000202 ORIG_RAX: 0000000000000101 [ 35.104263] RAX: ffffffffffffffda RBX: 0000000000000242 RCX: 00007f9134d81fc1 [ 35.105452] RDX: 0000000000000242 RSI: 00007ffcd41e1200 RDI: 00000000ffffff9c [ 35.106663] RBP: 00007ffcd41e1200 R08: 0000000000000000 R09: 0000000000000064 [ 35.107923] R10: 00000000000001a4 R11: 0000000000000202 R12: 0000000000000066 [ 35.109112] R13: 0000000000100000 R14: 0000000000100000 R15: 0000000000000400 [ 35.110357] </TASK> [ 35.110769] irq event stamp: 8415587 [ 35.111486] hardirqs last enabled at (8415599): [<ffffffff8d74b562>] __up_console_sem+0x52/0x60 [ 35.113067] hardirqs last disabled at (8415610): [<ffffffff8d74b547>] __up_console_sem+0x37/0x60 [ 35.114575] softirqs last enabled at (8415300): [<ffffffff8d6ac625>] handle_softirqs+0x315/0x3f0 [ 35.115933] softirqs last disabled at (8415291): [<ffffffff8d6ac811>] __irq_exit_rcu+0xa1/0xc0 [ 35.117316] ---[ end trace 0000000000000000 ]--- Fix this by using xas_reset() instead, which is equivalent in implementation to xas_pause() but does not advance the XArray state. Link: https://lkml.kernel.org/r/20250523043749.1460780-1-apopple@nvidia.com Fixes: 6be3e21d25ca ("fs/dax: don't skip locked entries when scanning entries") Signed-off-by: Alistair Popple <apopple(a)nvidia.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Cc: Alison Schofield <alison.schofield(a)intel.com> Cc: Matthew Wilcow (Oracle) <willy(a)infradead.org> Cc: Balbir Singh <balbirs(a)nvidia.com> Cc: "Darrick J. Wong" <djwong(a)kernel.org> Cc: Dave Chinner <david(a)fromorbit.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Ted Ts'o <tytso(a)mit.edu> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/dax.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/dax.c~fs-dax-fix-dont-skip-locked-entries-when-scanning-entries +++ a/fs/dax.c @@ -257,7 +257,7 @@ static void *wait_entry_unlocked_exclusi wq = dax_entry_waitqueue(xas, entry, &ewait.key); prepare_to_wait_exclusive(wq, &ewait.wait, TASK_UNINTERRUPTIBLE); - xas_pause(xas); + xas_reset(xas); xas_unlock_irq(xas); schedule(); finish_wait(wq, &ewait.wait); _ Patches currently in -mm which might be from apopple(a)nvidia.com are maintainers-add-myself-as-reviewer-of-mm-memory-policy.patch

3 months, 4 weeks

1
0
0 0

+ mm-madvise-handle-madvise_lock-failure-during-race-unwinding.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/madvise: handle madvise_lock() failure during race unwinding has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-madvise-handle-madvise_lock-failure-during-race-unwinding.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: SeongJae Park <sj(a)kernel.org> Subject: mm/madvise: handle madvise_lock() failure during race unwinding Date: Mon, 2 Jun 2025 10:49:26 -0700 When unwinding race on -ERESTARTNOINTR handling of process_madvise(), madvise_lock() failure is ignored. Check the failure and abort remaining works in the case. Link: https://lkml.kernel.org/r/20250602174926.1074-1-sj@kernel.org Fixes: 4000e3d0a367 ("mm/madvise: remove redundant mmap_lock operations from process_madvise()") Signed-off-by: SeongJae Park <sj(a)kernel.org> Reported-by: Barry Song <21cnbao(a)gmail.com> Closes: https://lore.kernel.org/CAGsJ_4xJXXO0G+4BizhohSZ4yDteziPw43_uF8nPXPWxUVChzw… Reviewed-by: Jann Horn <jannh(a)google.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Acked-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Shakeel Butt <shakeel.butt(a)linux.dev> Reviewed-by: Barry Song <baohua(a)kernel.org> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/madvise.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/mm/madvise.c~mm-madvise-handle-madvise_lock-failure-during-race-unwinding +++ a/mm/madvise.c @@ -1881,7 +1881,9 @@ static ssize_t vector_madvise(struct mm_ /* Drop and reacquire lock to unwind race. */ madvise_finish_tlb(&madv_behavior); madvise_unlock(mm, behavior); - madvise_lock(mm, behavior); + ret = madvise_lock(mm, behavior); + if (ret) + goto out; madvise_init_tlb(&madv_behavior, mm); continue; } @@ -1892,6 +1894,7 @@ static ssize_t vector_madvise(struct mm_ madvise_finish_tlb(&madv_behavior); madvise_unlock(mm, behavior); +out: ret = (total_len - iov_iter_count(iter)) ? : ret; return ret; _ Patches currently in -mm which might be from sj(a)kernel.org are mm-madvise-handle-madvise_lock-failure-during-race-unwinding.patch mm-damon-kconfig-set-damon_vaddrpaddrsysfs-default-to-damon.patch mm-damon-kconfig-enable-config_damon-by-default.patch

3 months, 4 weeks

1
0
0 0

[PATCH 5.10] netfilter: nft_socket: fix sk refcount leaks

by Denis Arefev

From: Florian Westphal <fw(a)strlen.de> commit 8b26ff7af8c32cb4148b3e147c52f9e4c695209c upstream. We must put 'sk' reference before returning. Fixes: 039b1f4f24ec ("netfilter: nft_socket: fix erroneous socket assignment") Signed-off-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-46855 Link: https://nvd.nist.gov/vuln/detail/CVE-2024-46855 --- net/netfilter/nft_socket.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nft_socket.c b/net/netfilter/nft_socket.c index 826e5f8c78f3..07e73e50b713 100644 --- a/net/netfilter/nft_socket.c +++ b/net/netfilter/nft_socket.c @@ -88,13 +88,13 @@ static void nft_socket_eval(const struct nft_expr *expr, *dest = sk->sk_mark; } else { regs->verdict.code = NFT_BREAK; - return; + goto out_put_sk; } break; case NFT_SOCKET_WILDCARD: if (!sk_fullsock(sk)) { regs->verdict.code = NFT_BREAK; - return; + goto out_put_sk; } nft_socket_wildcard(pkt, regs, sk, dest); break; @@ -103,6 +103,7 @@ static void nft_socket_eval(const struct nft_expr *expr, regs->verdict.code = NFT_BREAK; } +out_put_sk: if (sk != skb->sk) sock_gen_put(sk); } -- 2.43.0

3 months, 4 weeks

3
2
0 0

[PATCH 1/6] cifs: deal with the channel loading lag while picking channels

by nspmangalore＠gmail.com

From: Shyam Prasad N <sprasad(a)microsoft.com> Our current approach to select a channel for sending requests is this: 1. iterate all channels to find the min and max queue depth 2. if min and max are not the same, pick the channel with min depth 3. if min and max are same, round robin, as all channels are equally loaded The problem with this approach is that there's a lag between selecting a channel and sending the request (that increases the queue depth on the channel). While these numbers will eventually catch up, there could be a skew in the channel usage, depending on the application's I/O parallelism and the server's speed of handling requests. With sufficient parallelism, this lag can artificially increase the queue depth, thereby impacting the performance negatively. This change will change the step 1 above to start the iteration from the last selected channel. This is to reduce the skew in channel usage even in the presence of this lag. Fixes: ea90708d3cf3 ("cifs: use the least loaded channel for sending requests") Cc: <stable(a)vger.kernel.org> Signed-off-by: Shyam Prasad N <sprasad(a)microsoft.com> --- fs/smb/client/transport.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fs/smb/client/transport.c b/fs/smb/client/transport.c index 266af17aa7d9..191783f553ce 100644 --- a/fs/smb/client/transport.c +++ b/fs/smb/client/transport.c @@ -1018,14 +1018,16 @@ struct TCP_Server_Info *cifs_pick_channel(struct cifs_ses *ses) uint index = 0; unsigned int min_in_flight = UINT_MAX, max_in_flight = 0; struct TCP_Server_Info *server = NULL; - int i; + int i, start, cur; if (!ses) return NULL; spin_lock(&ses->chan_lock); + start = atomic_inc_return(&ses->chan_seq); for (i = 0; i < ses->chan_count; i++) { - server = ses->chans[i].server; + cur = (start + i) % ses->chan_count; + server = ses->chans[cur].server; if (!server || server->terminate) continue; @@ -1042,17 +1044,15 @@ struct TCP_Server_Info *cifs_pick_channel(struct cifs_ses *ses) */ if (server->in_flight < min_in_flight) { min_in_flight = server->in_flight; - index = i; + index = cur; } if (server->in_flight > max_in_flight) max_in_flight = server->in_flight; } /* if all channels are equally loaded, fall back to round-robin */ - if (min_in_flight == max_in_flight) { - index = (uint)atomic_inc_return(&ses->chan_seq); - index %= ses->chan_count; - } + if (min_in_flight == max_in_flight) + index = (uint)start % ses->chan_count; server = ses->chans[index].server; spin_unlock(&ses->chan_lock); -- 2.43.0

3 months, 4 weeks

2
3
0 0

[PATCH] arm64: Add MIDR-based check for FEAT_ECBHB

by Oliver Upton

Prior to commit e8cde32f111f ("arm64/cpufeatures/kvm: Add ARMv8.9 FEAT_ECBHB bits in ID_AA64MMFR1 register") KVM was erroneously masking FEAT_ECBHB from VMs, giving the perception that safe implementations are actually vulnerable to Spectre-BHB. And, after commit e403e8538359 ("arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre BHB") guests are enabling the loop mitigation. This broken virtual hardware is going to be around for some time, so do the ugly thing and check for revisions of Neoverse-V2 [1], Cortex-X3 [2], Cortex-A720 [3], and Neoverse-N3 [4] that are documented to have FEAT_ECBHB. Cc: stable(a)vger.kernel.org Link: https://developer.arm.com/documentation/102375/0002 Link: https://developer.arm.com/documentation/101593/0102 Link: https://developer.arm.com/documentation/102530/0002 Link: https://developer.arm.com/documentation/107997/0001 Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> --- I thoroughly hate this but the alternative of nuking these busted VMs isn't exactly popular... arch/arm64/include/asm/cputype.h | 1 + arch/arm64/kernel/proton-pack.c | 16 ++++++++++++++++ 2 files changed, 17 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index d1cc0571798b..5c6152e61cad 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -282,6 +282,7 @@ struct midr_range { #define MIDR_REV_RANGE(m, v, r_min, r_max) MIDR_RANGE(m, v, r_min, v, r_max) #define MIDR_REV(m, v, r) MIDR_RANGE(m, v, r, v, r) #define MIDR_ALL_VERSIONS(m) MIDR_RANGE(m, 0, 0, 0xf, 0xf) +#define MIDR_MIN_VERSION(m, v, r) MIDR_RANGE(m, v, r, 0xf, 0xf) static inline bool midr_is_cpu_model_range(u32 midr, u32 model, u32 rv_min, u32 rv_max) diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c index b198dde79e59..3d00d4c22d58 100644 --- a/arch/arm64/kernel/proton-pack.c +++ b/arch/arm64/kernel/proton-pack.c @@ -962,8 +962,24 @@ static bool has_spectre_bhb_fw_mitigation(void) static bool supports_ecbhb(int scope) { + static const struct midr_range spectre_ecbhb_list[] = { + MIDR_MIN_VERSION(MIDR_NEOVERSE_V2, 0, 2), + MIDR_MIN_VERSION(MIDR_CORTEX_X3, 1, 1), + MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N3), + MIDR_MIN_VERSION(MIDR_CORTEX_A720, 0, 1), + {}, + }; u64 mmfr1; + /* + * Prior to commit e8cde32f111f ("arm64/cpufeatures/kvm: Add ARMv8.9 + * FEAT_ECBHB bits in ID_AA64MMFR1 register"), KVM masked FEAT_ECBHB + * on implementations that actually have the feature. That sucks; infer + * presence of FEAT_ECBHB based on MIDR. + */ + if (is_midr_in_range_list(spectre_ecbhb_list)) + return true; + if (scope == SCOPE_LOCAL_CPU) mmfr1 = read_sysreg_s(SYS_ID_AA64MMFR1_EL1); else base-commit: b4432656b36e5cc1d50a1f2dc15357543add530e -- 2.39.5

3 months, 4 weeks

2
2
0 0

[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>

3 months, 4 weeks

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

3 months, 4 weeks

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

3 months, 4 weeks

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

3 months, 4 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2025