February 2025 - Linux-stable-mirror

[PATCH v6 4/8] crypto: ccp: Fix uapi definitions of PSP errors

by Dionna Glaze

From: Alexey Kardashevskiy <aik(a)amd.com> Additions to the error enum after the explicit 0x27 setting for SEV_RET_INVALID_KEY leads to incorrect value assignments. Use explicit values to match the manufacturer specifications more clearly. Fixes: 3a45dc2b419e ("crypto: ccp: Define the SEV-SNP commands") CC: Sean Christopherson <seanjc(a)google.com> CC: Paolo Bonzini <pbonzini(a)redhat.com> CC: Thomas Gleixner <tglx(a)linutronix.de> CC: Ingo Molnar <mingo(a)redhat.com> CC: Borislav Petkov <bp(a)alien8.de> CC: Dave Hansen <dave.hansen(a)linux.intel.com> CC: Ashish Kalra <ashish.kalra(a)amd.com> CC: Tom Lendacky <thomas.lendacky(a)amd.com> CC: John Allen <john.allen(a)amd.com> CC: Herbert Xu <herbert(a)gondor.apana.org.au> CC: "David S. Miller" <davem(a)davemloft.net> CC: Michael Roth <michael.roth(a)amd.com> CC: Luis Chamberlain <mcgrof(a)kernel.org> CC: Russ Weight <russ.weight(a)linux.dev> CC: Danilo Krummrich <dakr(a)redhat.com> CC: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> CC: "Rafael J. Wysocki" <rafael(a)kernel.org> CC: Tianfei zhang <tianfei.zhang(a)intel.com> CC: Alexey Kardashevskiy <aik(a)amd.com> CC: stable(a)vger.kernel.org Signed-off-by: Alexey Kardashevskiy <aik(a)amd.com> Signed-off-by: Dionna Glaze <dionnaglaze(a)google.com> --- include/uapi/linux/psp-sev.h | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h index 832c15d9155bd..eeb20dfb1fdaa 100644 --- a/include/uapi/linux/psp-sev.h +++ b/include/uapi/linux/psp-sev.h @@ -73,13 +73,20 @@ typedef enum { SEV_RET_INVALID_PARAM, SEV_RET_RESOURCE_LIMIT, SEV_RET_SECURE_DATA_INVALID, - SEV_RET_INVALID_KEY = 0x27, - SEV_RET_INVALID_PAGE_SIZE, - SEV_RET_INVALID_PAGE_STATE, - SEV_RET_INVALID_MDATA_ENTRY, - SEV_RET_INVALID_PAGE_OWNER, - SEV_RET_INVALID_PAGE_AEAD_OFLOW, - SEV_RET_RMP_INIT_REQUIRED, + SEV_RET_INVALID_PAGE_SIZE = 0x0019, + SEV_RET_INVALID_PAGE_STATE = 0x001A, + SEV_RET_INVALID_MDATA_ENTRY = 0x001B, + SEV_RET_INVALID_PAGE_OWNER = 0x001C, + SEV_RET_AEAD_OFLOW = 0x001D, + SEV_RET_EXIT_RING_BUFFER = 0x001F, + SEV_RET_RMP_INIT_REQUIRED = 0x0020, + SEV_RET_BAD_SVN = 0x0021, + SEV_RET_BAD_VERSION = 0x0022, + SEV_RET_SHUTDOWN_REQUIRED = 0x0023, + SEV_RET_UPDATE_FAILED = 0x0024, + SEV_RET_RESTORE_REQUIRED = 0x0025, + SEV_RET_RMP_INITIALIZATION_FAILED = 0x0026, + SEV_RET_INVALID_KEY = 0x0027, SEV_RET_MAX, } sev_ret_code; -- 2.47.0.277.g8800431eea-goog

2 months, 3 weeks

4
6
0 0

[PATCH] PCI: controller: Restore PCI_REASSIGN_ALL_BUS when PCI_PROBE_ONLY is enabled

by Bo Sun

On our Marvell OCTEON CN96XX board, we observed the following panic on the latest kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [0000000000000080] user address but active_mm is swapper Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: CPU: 9 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.13.0-rc7-00149-g9bffa1ad25b8 #1 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : of_pci_add_properties+0x278/0x4c8 lr : of_pci_add_properties+0x258/0x4c8 sp : ffff8000822ef9b0 x29: ffff8000822ef9b0 x28: ffff000106dd8000 x27: ffff800081bc3b30 x26: ffff800081540118 x25: ffff8000813d2be0 x24: 0000000000000000 x23: ffff00010528a800 x22: ffff000107c50000 x21: ffff0001039c2630 x20: ffff0001039c2630 x19: 0000000000000000 x18: ffffffffffffffff x17: 00000000a49c1b85 x16: 0000000084c07b58 x15: ffff000103a10f98 x14: ffffffffffffffff x13: ffff000103a10f96 x12: 0000000000000003 x11: 0101010101010101 x10: 000000000000002c x9 : ffff800080ca7acc x8 : ffff0001038fd900 x7 : 0000000000000000 x6 : 0000000000696370 x5 : 0000000000000000 x4 : 0000000000000002 x3 : ffff8000822efa40 x2 : ffff800081341000 x1 : ffff000107c50000 x0 : 0000000000000000 Call trace: of_pci_add_properties+0x278/0x4c8 (P) of_pci_make_dev_node+0xe0/0x158 pci_bus_add_device+0x158/0x210 pci_bus_add_devices+0x40/0x98 pci_host_probe+0x94/0x118 pci_host_common_probe+0x120/0x1a0 platform_probe+0x70/0xf0 really_probe+0xb4/0x2a8 __driver_probe_device+0x80/0x140 driver_probe_device+0x48/0x170 __driver_attach+0x9c/0x1b0 bus_for_each_dev+0x7c/0xe8 driver_attach+0x2c/0x40 bus_add_driver+0xec/0x218 driver_register+0x68/0x138 __platform_driver_register+0x2c/0x40 gen_pci_driver_init+0x24/0x38 do_one_initcall+0x4c/0x278 kernel_init_freeable+0x1f4/0x3d0 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 Code: aa1603e1 f0005522 d2800044 91000042 (f94040a0) This regression was introduced by commit 7246a4520b4b ("PCI: Use preserve_config in place of pci_flags"). On our board, the 002:00:07.0 bridge is misconfigured by the bootloader. Both its secondary and subordinate bus numbers are initialized to 0, while its fixed secondary bus number is set to 8. However, bus number 8 is also assigned to another bridge (0002:00:0f.0). Although this is a bootloader issue, before the change in commit 7246a4520b4b, the PCI_REASSIGN_ALL_BUS flag was set by default when PCI_PROBE_ONLY was enabled, ensuing that all the bus number for these bridges were reassigned, avoiding any conflicts. After the change introduced in commit 7246a4520b4b, the bus numbers assigned by the bootloader are reused by all other bridges, except the misconfigured 002:00:07.0 bridge. The kernel attempt to reconfigure 002:00:07.0 by reusing the fixed secondary bus number 8 assigned by bootloader. However, since a pci_bus has already been allocated for bus 8 due to the probe of 0002:00:0f.0, no new pci_bus allocated for 002:00:07.0. This results in a pci bridge device without a pci_bus attached (pdev->subordinate == NULL). Consequently, accessing pdev->subordinate in of_pci_prop_bus_range() leads to a NULL pointer dereference. To summarize, we need to restore the PCI_REASSIGN_ALL_BUS flag when PCI_PROBE_ONLY is enabled in order to work around issue like the one described above. Cc: stable(a)vger.kernel.org Fixes: 7246a4520b4b ("PCI: Use preserve_config in place of pci_flags") Signed-off-by: Bo Sun <Bo.Sun.CN(a)windriver.com> --- drivers/pci/controller/pci-host-common.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/pci/controller/pci-host-common.c b/drivers/pci/controller/pci-host-common.c index cf5f59a745b3..615923acbc3e 100644 --- a/drivers/pci/controller/pci-host-common.c +++ b/drivers/pci/controller/pci-host-common.c @@ -73,6 +73,10 @@ int pci_host_common_probe(struct platform_device *pdev) if (IS_ERR(cfg)) return PTR_ERR(cfg); + /* Do not reassign resources if probe only */ + if (!pci_has_flag(PCI_PROBE_ONLY)) + pci_add_flags(PCI_REASSIGN_ALL_BUS); + bridge->sysdata = cfg; bridge->ops = (struct pci_ops *)&ops->pci_ops; bridge->msi_domain = true; -- 2.48.1

2 months, 3 weeks

4
9
0 0

Re: [PATCH] net: fix uninitialised access in mii_nway_restart()

by Qasim Ijaz

On Tue, Feb 18, 2025 at 02:10:08AM +0100, Andrew Lunn wrote: > On Tue, Feb 18, 2025 at 12:24:43AM +0000, Qasim Ijaz wrote: > > In mii_nway_restart() during the line: > > > > bmcr = mii->mdio_read(mii->dev, mii->phy_id, MII_BMCR); > > > > The code attempts to call mii->mdio_read which is ch9200_mdio_read(). > > > > ch9200_mdio_read() utilises a local buffer, which is initialised > > with control_read(): > > > > unsigned char buff[2]; > > > > However buff is conditionally initialised inside control_read(): > > > > if (err == size) { > > memcpy(data, buf, size); > > } > > > > If the condition of "err == size" is not met, then buff remains > > uninitialised. Once this happens the uninitialised buff is accessed > > and returned during ch9200_mdio_read(): > > > > return (buff[0] | buff[1] << 8); > > > > The problem stems from the fact that ch9200_mdio_read() ignores the > > return value of control_read(), leading to uinit-access of buff. > > > > To fix this we should check the return value of control_read() > > and return early on error. > > What about get_mac_address()? > > If you find a bug, it is a good idea to look around and see if there > are any more instances of the same bug. I could be wrong, but it seems > like get_mac_address() suffers from the same problem? Thank you for the feedback Andrew. I checked get_mac_address() before sending this patch and to me it looks like it does check the return value of control_read(). It accumulates the return value of each control_read() call into rd_mac_len and then checks if it not equal to what is expected (ETH_ALEN which is 6), I believe each call should return 2. > > Andrew

2 months, 3 weeks

2
3
0 0

Apply 3 commits for 6.13.y

by Miguel Ojeda

Hi Greg, Sasha, Please consider applying the following commits for 6.13.y: 27c7518e7f1c ("rust: finish using custom FFI integer types") 1bae8729e50a ("rust: map `long` to `isize` and `char` to `u8`") 9b98be76855f ("rust: cleanup unnecessary casts") They should apply cleanly. This backports the custom FFI integer types, which in turn solves a build failure under `CONFIG_RUST_FW_LOADER_ABSTRACTIONS=y`. I will have to send something similar to 6.12.y, but it requires more commits -- I may do the `alloc` backport first we discussed the other day. Thanks! Cheers, Miguel

2 months, 3 weeks

4
5
0 0

[PATCH v2] tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN

by Günther Noack

With this, processes without CAP_SYS_ADMIN are able to use TIOCLINUX with subcode TIOCL_SETSEL, in the selection modes TIOCL_SETPOINTER, TIOCL_SELCLEAR and TIOCL_SELMOUSEREPORT. TIOCL_SETSEL was previously changed to require CAP_SYS_ADMIN, as this IOCTL let callers change the selection buffer and could be used to simulate keypresses. These three TIOCL_SETSEL selection modes, however, are safe to use, as they do not modify the selection buffer. This fixes a mouse support regression that affected Emacs (invisible mouse cursor). Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/ee3ec63269b43b34e1c90dd8c9743bf8@finder.org Fixes: 8d1b43f6a6df ("tty: Restrict access to TIOCLINUX' copy-and-paste subcommands") Signed-off-by: Günther Noack <gnoack(a)google.com> --- Changes in V2: * Removed comment in vt.c (per Greg's suggestion) * CC'd stable@ * I *kept* the CAP_SYS_ADMIN check *after* copy_from_user(), with the reasoning that: 1. I do not see a good alternative to reorder the code here. We need the data from copy_from_user() in order to know whether the CAP_SYS_ADMIN check even needs to be performed. 2. A previous get_user() from an adjacent memory region already worked (making this a very unlikely failure) I would still appreciate a more formal Tested-by from Hanno (hint, hint) :) --- drivers/tty/vt/selection.c | 14 ++++++++++++++ drivers/tty/vt/vt.c | 2 -- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c index 564341f1a74f..0bd6544e30a6 100644 --- a/drivers/tty/vt/selection.c +++ b/drivers/tty/vt/selection.c @@ -192,6 +192,20 @@ int set_selection_user(const struct tiocl_selection __user *sel, if (copy_from_user(&v, sel, sizeof(*sel))) return -EFAULT; + /* + * TIOCL_SELCLEAR, TIOCL_SELPOINTER and TIOCL_SELMOUSEREPORT are OK to + * use without CAP_SYS_ADMIN as they do not modify the selection. + */ + switch (v.sel_mode) { + case TIOCL_SELCLEAR: + case TIOCL_SELPOINTER: + case TIOCL_SELMOUSEREPORT: + break; + default: + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + } + return set_selection_kernel(&v, tty); } diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index 96842ce817af..be5564ed8c01 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -3345,8 +3345,6 @@ int tioclinux(struct tty_struct *tty, unsigned long arg) switch (type) { case TIOCL_SETSEL: - if (!capable(CAP_SYS_ADMIN)) - return -EPERM; return set_selection_user(param, tty); case TIOCL_PASTESEL: if (!capable(CAP_SYS_ADMIN)) -- 2.47.1.613.gc27f4b7a9f-goog

2 months, 3 weeks

6
13
0 0

[PATCH v2] arm64: dts: ti: k3-j784s4-j742s2-main-common: Fix serdes_ln_ctrl reg-masks

by Siddharth Vadapalli

Commit under Fixes added the 'idle-states' property for SERDES4 lane muxes without defining the corresponding register offsets and masks for it in the 'mux-reg-masks' property within the 'serdes_ln_ctrl' node. Fix this. Fixes: 7287d423f138 ("arm64: dts: ti: k3-j784s4-main: Add system controller and SERDES lane mux") Cc: stable(a)vger.kernel.org Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com> --- Patch is based on commit 76544811c850 Merge tag 'drm-fixes-2025-02-28' of https://gitlab.freedesktop.org/drm/kernel of the master branch of Mainline Linux. v1: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20250227061643.… Changes since v1: - Updated offsets to begin from 0x40 instead of 0x30. This is because SERDES3 is not present in J784S4. Regards, Siddharth. arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi index 83bbf94b58d1..51cb8f3fd1c8 100644 --- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi +++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi @@ -84,7 +84,9 @@ serdes_ln_ctrl: mux-controller@4080 { <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */ <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */ <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */ - <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */ + <0x28 0x3>, <0x2c 0x3>, /* SERDES2 lane2/3 select */ + <0x40 0x3>, <0x44 0x3>, /* SERDES4 lane0/1 select */ + <0x48 0x3>, <0x4c 0x3>; /* SERDES4 lane2/3 select */ idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>, <J784S4_SERDES0_LANE1_PCIE1_LANE1>, <J784S4_SERDES0_LANE2_IP3_UNUSED>, -- 2.34.1

2 months, 3 weeks

2
1
0 0

FAILED: patch "[PATCH] drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macro" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 879f70382ff3e92fc854589ada3453e3f5f5b601 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025022418-clergyman-hacker-f7f7@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 879f70382ff3e92fc854589ada3453e3f5f5b601 Mon Sep 17 00:00:00 2001 From: Imre Deak <imre.deak(a)intel.com> Date: Fri, 14 Feb 2025 16:19:51 +0200 Subject: [PATCH] drm/i915/dsi: Use TRANS_DDI_FUNC_CTL's own port width macro The format of the port width field in the DDI_BUF_CTL and the TRANS_DDI_FUNC_CTL registers are different starting with MTL, where the x3 lane mode for HDMI FRL has a different encoding in the two registers. To account for this use the TRANS_DDI_FUNC_CTL's own port width macro. Cc: <stable(a)vger.kernel.org> # v6.5+ Fixes: b66a8abaa48a ("drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI") Reviewed-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Imre Deak <imre.deak(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250214142001.552916-2-imre.… (cherry picked from commit 76120b3a304aec28fef4910204b81a12db8974da) Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c b/drivers/gpu/drm/i915/display/icl_dsi.c index c977b74f82f0..82bf6c654de2 100644 --- a/drivers/gpu/drm/i915/display/icl_dsi.c +++ b/drivers/gpu/drm/i915/display/icl_dsi.c @@ -809,8 +809,8 @@ gen11_dsi_configure_transcoder(struct intel_encoder *encoder, /* select data lane width */ tmp = intel_de_read(display, TRANS_DDI_FUNC_CTL(display, dsi_trans)); - tmp &= ~DDI_PORT_WIDTH_MASK; - tmp |= DDI_PORT_WIDTH(intel_dsi->lane_count); + tmp &= ~TRANS_DDI_PORT_WIDTH_MASK; + tmp |= TRANS_DDI_PORT_WIDTH(intel_dsi->lane_count); /* select input pipe */ tmp &= ~TRANS_DDI_EDP_INPUT_MASK;

2 months, 3 weeks

4
5
0 0

[PATCH v1 2/2] mm/slab/kvfree_rcu: Switch to WQ_MEM_RECLAIM wq

by Uladzislau Rezki (Sony)

Currently kvfree_rcu() APIs use a system workqueue which is "system_unbound_wq" to driver RCU machinery to reclaim a memory. Recently, it has been noted that the following kernel warning can be observed: <snip> workqueue: WQ_MEM_RECLAIM nvme-wq:nvme_scan_work is flushing !WQ_MEM_RECLAIM events_unbound:kfree_rcu_work WARNING: CPU: 21 PID: 330 at kernel/workqueue.c:3719 check_flush_dependency+0x112/0x120 Modules linked in: intel_uncore_frequency(E) intel_uncore_frequency_common(E) skx_edac(E) ... CPU: 21 UID: 0 PID: 330 Comm: kworker/u144:6 Tainted: G E 6.13.2-0_g925d379822da #1 Hardware name: Wiwynn Twin Lakes MP/Twin Lakes Passive MP, BIOS YMM20 02/01/2023 Workqueue: nvme-wq nvme_scan_work RIP: 0010:check_flush_dependency+0x112/0x120 Code: 05 9a 40 14 02 01 48 81 c6 c0 00 00 00 48 8b 50 18 48 81 c7 c0 00 00 00 48 89 f9 48 ... RSP: 0018:ffffc90000df7bd8 EFLAGS: 00010082 RAX: 000000000000006a RBX: ffffffff81622390 RCX: 0000000000000027 RDX: 00000000fffeffff RSI: 000000000057ffa8 RDI: ffff88907f960c88 RBP: 0000000000000000 R08: ffffffff83068e50 R09: 000000000002fffd R10: 0000000000000004 R11: 0000000000000000 R12: ffff8881001a4400 R13: 0000000000000000 R14: ffff88907f420fb8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88907f940000(0000) knlGS:0000000000000000 CR2: 00007f60c3001000 CR3: 000000107d010005 CR4: 00000000007726f0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xa4/0x140 ? check_flush_dependency+0x112/0x120 ? report_bug+0xe1/0x140 ? check_flush_dependency+0x112/0x120 ? handle_bug+0x5e/0x90 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? timer_recalc_next_expiry+0x190/0x190 ? check_flush_dependency+0x112/0x120 ? check_flush_dependency+0x112/0x120 __flush_work.llvm.1643880146586177030+0x174/0x2c0 flush_rcu_work+0x28/0x30 kvfree_rcu_barrier+0x12f/0x160 kmem_cache_destroy+0x18/0x120 bioset_exit+0x10c/0x150 disk_release.llvm.6740012984264378178+0x61/0xd0 device_release+0x4f/0x90 kobject_put+0x95/0x180 nvme_put_ns+0x23/0xc0 nvme_remove_invalid_namespaces+0xb3/0xd0 nvme_scan_work+0x342/0x490 process_scheduled_works+0x1a2/0x370 worker_thread+0x2ff/0x390 ? pwq_release_workfn+0x1e0/0x1e0 kthread+0xb1/0xe0 ? __kthread_parkme+0x70/0x70 ret_from_fork+0x30/0x40 ? __kthread_parkme+0x70/0x70 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- <snip> To address this switch to use of independent WQ_MEM_RECLAIM workqueue, so the rules are not violated from workqueue framework point of view. Apart of that, since kvfree_rcu() does reclaim memory it is worth to go with WQ_MEM_RECLAIM type of wq because it is designed for this purpose. Cc: <stable(a)vger.kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Keith Busch <kbusch(a)kernel.org> Closes: https://www.spinics.net/lists/kernel/msg5563270.html Fixes: 6c6c47b063b5 ("mm, slab: call kvfree_rcu_barrier() from kmem_cache_destroy()"), Reported-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Uladzislau Rezki (Sony) <urezki(a)gmail.com> --- mm/slab_common.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/mm/slab_common.c b/mm/slab_common.c index 4030907b6b7d..4c9f0a87f733 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -1304,6 +1304,8 @@ module_param(rcu_min_cached_objs, int, 0444); static int rcu_delay_page_cache_fill_msec = 5000; module_param(rcu_delay_page_cache_fill_msec, int, 0444); +static struct workqueue_struct *rcu_reclaim_wq; + /* Maximum number of jiffies to wait before draining a batch. */ #define KFREE_DRAIN_JIFFIES (5 * HZ) #define KFREE_N_BATCHES 2 @@ -1632,10 +1634,10 @@ __schedule_delayed_monitor_work(struct kfree_rcu_cpu *krcp) if (delayed_work_pending(&krcp->monitor_work)) { delay_left = krcp->monitor_work.timer.expires - jiffies; if (delay < delay_left) - mod_delayed_work(system_unbound_wq, &krcp->monitor_work, delay); + mod_delayed_work(rcu_reclaim_wq, &krcp->monitor_work, delay); return; } - queue_delayed_work(system_unbound_wq, &krcp->monitor_work, delay); + queue_delayed_work(rcu_reclaim_wq, &krcp->monitor_work, delay); } static void @@ -1733,7 +1735,7 @@ kvfree_rcu_queue_batch(struct kfree_rcu_cpu *krcp) // "free channels", the batch can handle. Break // the loop since it is done with this CPU thus // queuing an RCU work is _always_ success here. - queued = queue_rcu_work(system_unbound_wq, &krwp->rcu_work); + queued = queue_rcu_work(rcu_reclaim_wq, &krwp->rcu_work); WARN_ON_ONCE(!queued); break; } @@ -1883,7 +1885,7 @@ run_page_cache_worker(struct kfree_rcu_cpu *krcp) if (rcu_scheduler_active == RCU_SCHEDULER_RUNNING && !atomic_xchg(&krcp->work_in_progress, 1)) { if (atomic_read(&krcp->backoff_page_cache_fill)) { - queue_delayed_work(system_unbound_wq, + queue_delayed_work(rcu_reclaim_wq, &krcp->page_cache_work, msecs_to_jiffies(rcu_delay_page_cache_fill_msec)); } else { @@ -2120,6 +2122,10 @@ void __init kvfree_rcu_init(void) int i, j; struct shrinker *kfree_rcu_shrinker; + rcu_reclaim_wq = alloc_workqueue("kvfree_rcu_reclaim", + WQ_UNBOUND | WQ_MEM_RECLAIM, 0); + WARN_ON(!rcu_reclaim_wq); + /* Clamp it to [0:100] seconds interval. */ if (rcu_delay_page_cache_fill_msec < 0 || rcu_delay_page_cache_fill_msec > 100 * MSEC_PER_SEC) { -- 2.39.5

2 months, 3 weeks

5
5
0 0

[PATCH] arm64: tegra: delete the Orin NX/Nano suspend key

by Ivy Huang

From: Ninad Malwade <nmalwade(a)nvidia.com> As per the Orin Nano Dev Kit schematic, GPIO_G.02 is not available on this device family. It should not be used at all on Orin NX/Nano. Having this unused pin mapped as the suspend key can lead to unpredictable behavior for low power modes. Orin NX/Nano uses GPIO_EE.04 as both a "power" button and a "suspend" button. However, we cannot have two gpio-keys mapped to the same GPIO. Therefore delete the "suspend" key. Cc: stable(a)vger.kernel.org Fixes: e63472eda5ea ("arm64: tegra: Support Jetson Orin NX reference platform") Signed-off-by: Ninad Malwade <nmalwade(a)nvidia.com> Signed-off-by: Ivy Huang <yijuh(a)nvidia.com> --- arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi | 7 ------- 1 file changed, 7 deletions(-) diff --git a/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi b/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi index 19340d13f789..41821354bbda 100644 --- a/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi @@ -227,13 +227,6 @@ wakeup-event-action = <EV_ACT_ASSERTED>; wakeup-source; }; - - key-suspend { - label = "Suspend"; - gpios = <&gpio TEGRA234_MAIN_GPIO(G, 2) GPIO_ACTIVE_LOW>; - linux,input-type = <EV_KEY>; - linux,code = <KEY_SLEEP>; - }; }; fan: pwm-fan { -- 2.17.1

2 months, 3 weeks

2
1
0 0

[PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

by Stefan Eichenberger

From: Stefan Eichenberger <stefan.eichenberger(a)toradex.com> When usb_control_msg is used in the get_bMaxPacketSize0 function, the USB pipe does not include the endpoint device number. This can cause failures when a usb hub port is reinitialized after encountering a bad cable connection. As a result, the system logs the following error messages: usb usb2-port1: cannot reset (err = -32) usb usb2-port1: Cannot enable. Maybe the USB cable is bad? usb usb2-port1: attempt power cycle usb 2-1: new high-speed USB device number 5 using ci_hdrc usb 2-1: device descriptor read/8, error -71 The problem began after commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads"). There usb_get_device_descriptor was replaced with get_bMaxPacketSize0. Unlike usb_get_device_descriptor, the get_bMaxPacketSize0 function uses the macro usb_rcvaddr0pipe, which does not include the endpoint device number. usb_get_device_descriptor, on the other hand, used the macro usb_rcvctrlpipe, which includes the endpoint device number. By modifying the get_bMaxPacketSize0 function to use usb_rcvctrlpipe instead of usb_rcvaddr0pipe, the issue can be resolved. This change will ensure that the endpoint device number is included in the USB pipe, preventing reinitialization failures. If the endpoint has not set the device number yet, it will still work because the device number is 0 in udev. Cc: stable(a)vger.kernel.org Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") Signed-off-by: Stefan Eichenberger <stefan.eichenberger(a)toradex.com> --- Before commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") usb_rcvaddr0pipe was used in hub_port_init. With this proposed change, usb_rcvctrlpipe will be used which includes devnum for the pipe. I'm not sure if this might have some side effects. However, my understanding is that devnum is set to the right value (might also be 0 if not initialised) before get_bMaxPacketSize0 is called. Therefore, this should work but please let me know if I'm wrong on this. --- drivers/usb/core/hub.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index c3f839637cb5..59e38780f76d 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -4698,7 +4698,6 @@ void usb_ep0_reinit(struct usb_device *udev) EXPORT_SYMBOL_GPL(usb_ep0_reinit); #define usb_sndaddr0pipe() (PIPE_CONTROL << 30) -#define usb_rcvaddr0pipe() ((PIPE_CONTROL << 30) | USB_DIR_IN) static int hub_set_address(struct usb_device *udev, int devnum) { @@ -4804,7 +4803,7 @@ static int get_bMaxPacketSize0(struct usb_device *udev, for (i = 0; i < GET_MAXPACKET0_TRIES; ++i) { /* Start with invalid values in case the transfer fails */ buf->bDescriptorType = buf->bMaxPacketSize0 = 0; - rc = usb_control_msg(udev, usb_rcvaddr0pipe(), + rc = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0), USB_REQ_GET_DESCRIPTOR, USB_DIR_IN, USB_DT_DEVICE << 8, 0, buf, size, -- 2.45.2

2 months, 3 weeks

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025