October 2023 - Linux-stable-mirror

[PATCH 5.10 0/4] cgroup: Fix suspicious rcu_dereference_check() warning

by ovidiu.panait＠windriver.com

From: Ovidiu Panait <ovidiu.panait(a)windriver.com> When booting the 5.10-stable kernel on the zcu102 board with CONFIG_PROVE_RCU=y, the following warning is present: ============================= WARNING: suspicious RCU usage 5.10.194-yocto-standard #1 Not tainted ----------------------------- include/linux/cgroup.h:495 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 9 locks held by kworker/2:2/106: #0: ffffff8800048948 ((wq_completion)events){..}-{0:0}, at: process_one_work+0x1f8/0x634 #1: ffffffc014c4bda8 (deferred_probe_work){..}-{0:0}, at: process_one_work+0x1f8/0x634 #2: ffffff880005d9a0 (&dev->mutex){....}-{3:3}, at: __device_attach+0x40/0x1c0 #3: ffffffc011c70cb0 (cpu_hotplug_lock){++++}-{0:0}, at: cpus_read_lock+0x18/0x24 #4: ffffff8800b10928 (subsys mutex#5){..}-{3:3}, at: subsys_interface_register+0x58/0x120 #5: ffffff8805e78c00 (&policy->rwsem){..}-{3:3}, at: cpufreq_online+0x590/0x960 #6: ffffffc012a9e770 (cpuset_mutex){..}-{3:3}, at: cpuset_lock+0x24/0x30 #7: ffffff880567bd80 (&p->pi_lock){..}-{2:2}, at: task_rq_lock+0x44/0xf0 #8: ffffff887aff50d8 (&rq->lock){..}-{2:2}, at: task_rq_lock+0x5c/0xf0 stack backtrace: CPU: 2 PID: 106 Comm: kworker/2:2 Not tainted 5.10.194-yocto-standard #1 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) Workqueue: events deferred_probe_work_func Call trace: dump_backtrace+0x0/0x1a4 show_stack+0x20/0x2c dump_stack+0xf0/0x13c lockdep_rcu_suspicious+0xe4/0xf8 inc_dl_tasks_cs+0xb8/0xbc switched_to_dl+0x38/0x280 __sched_setscheduler+0x204/0x860 sched_setattr_nocheck+0x20/0x30 sugov_init+0x1b8/0x380 cpufreq_init_governor.part.0+0x60/0xe0 cpufreq_set_policy+0x1d0/0x33c cpufreq_online+0x35c/0x960 cpufreq_add_dev+0x8c/0xa0 subsys_interface_register+0x10c/0x120 cpufreq_register_driver+0x148/0x2a4 dt_cpufreq_probe+0x288/0x3d0 platform_drv_probe+0x5c/0xb0 really_probe+0xe0/0x4ac driver_probe_device+0x60/0xf4 __device_attach_driver+0xc0/0x12c bus_for_each_drv+0x80/0xe0 __device_attach+0xb0/0x1c0 device_initial_probe+0x1c/0x30 bus_probe_device+0xa8/0xb0 deferred_probe_work_func+0x94/0xd0 process_one_work+0x2b8/0x634 worker_thread+0x7c/0x474 kthread+0x154/0x160 ret_from_fork+0x10/0x34 The warning was introduced in v5.10.193 by commit: 5ac05ce56843 "(sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets)" This issue was also reported for 5.15 here: https://lore.kernel.org/lkml/CA+G9fYv9xTu4bKJGy=e=KZSG5pZ+tJAmfZr=0dbuKNs=9… Backport commit f2aa197e4794 ("cgroup: Fix suspicious rcu_dereference_check() usage warning") and its dependencies to get rid of this warning. Andrey Ryabinin (1): sched/cpuacct: Fix user/system in shown cpuacct.usage* Chengming Zhou (3): sched/cpuacct: Fix charge percpu cpuusage sched/cpuacct: Optimize away RCU read lock cgroup: Fix suspicious rcu_dereference_check() usage warning include/linux/cgroup.h | 3 +- kernel/sched/cpuacct.c | 84 +++++++++++++++++------------------------- 2 files changed, 35 insertions(+), 52 deletions(-) -- 2.31.1

1 year, 6 months

2
5
0 0

[PATCH 1/4] megaraid_sas: Increase register read retry rount from 3 to 30 for selected registers

by Chandrakanth patil

In BMC environments with concurrent access to multiple registers, certain registers occasionally yield a value of 0 even after 3 retries due to hardware errata. As a fix, we have extended the retry count from 3 to 30. The same errata applies to the mpt3sas driver, and a similar patch has been accepted. Please find more details in the mpt3sas patch reference link. Link: https://lore.kernel.org/r/20230829090020.5417-2-ranjan.kumar@broadcom.com Fixes: 272652fcbf1a ("scsi: megaraid_sas: add retry logic in megasas_readl") Cc: stable(a)vger.kernel.org Signed-off-by: Chandrakanth patil <chandrakanth.patil(a)broadcom.com> Signed-off-by: Sumit Saxena <sumit.saxena(a)broadcom.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index e1aa667dae66..3d4f13da1ae8 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -263,13 +263,13 @@ u32 megasas_readl(struct megasas_instance *instance, * Fusion registers could intermittently return all zeroes. * This behavior is transient in nature and subsequent reads will * return valid value. As a workaround in driver, retry readl for - * upto three times until a non-zero value is read. + * up to thirty times until a non-zero value is read. */ if (instance->adapter_type == AERO_SERIES) { do { ret_val = readl(addr); i++; - } while (ret_val == 0 && i < 3); + } while (ret_val == 0 && i < 30); return ret_val; } else { return readl(addr); -- 2.39.3

1 year, 6 months

1
0
0 0

[PATCH net,v2, 1/3] net: mana: Fix TX CQE error handling

by Haiyang Zhang

For an unknown TX CQE error type (probably from a newer hardware), still free the SKB, update the queue tail, etc., otherwise the accounting will be wrong. Also, TX errors can be triggered by injecting corrupted packets, so replace the WARN_ONCE to ratelimited error logging. Cc: stable(a)vger.kernel.org Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> Reviewed-by: Simon Horman <horms(a)kernel.org> --- drivers/net/ethernet/microsoft/mana/mana_en.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c index 4a16ebff3d1d..5cdcf7561b38 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -1317,19 +1317,23 @@ static void mana_poll_tx_cq(struct mana_cq *cq) case CQE_TX_VPORT_IDX_OUT_OF_RANGE: case CQE_TX_VPORT_DISABLED: case CQE_TX_VLAN_TAGGING_VIOLATION: - WARN_ONCE(1, "TX: CQE error %d: ignored.\n", - cqe_oob->cqe_hdr.cqe_type); + if (net_ratelimit()) + netdev_err(ndev, "TX: CQE error %d\n", + cqe_oob->cqe_hdr.cqe_type); + apc->eth_stats.tx_cqe_err++; break; default: - /* If the CQE type is unexpected, log an error, assert, - * and go through the error path. + /* If the CQE type is unknown, log an error, + * and still free the SKB, update tail, etc. */ - WARN_ONCE(1, "TX: Unexpected CQE type %d: HW BUG?\n", - cqe_oob->cqe_hdr.cqe_type); + if (net_ratelimit()) + netdev_err(ndev, "TX: unknown CQE type %d\n", + cqe_oob->cqe_hdr.cqe_type); + apc->eth_stats.tx_cqe_unknown_type++; - return; + break; } if (WARN_ON_ONCE(txq->gdma_txq_id != completions[i].wq_num)) -- 2.25.1

1 year, 6 months

2
1
0 0

[PATCH net,v2, 2/3] net: mana: Fix the tso_bytes calculation

by Haiyang Zhang

sizeof(struct hop_jumbo_hdr) is not part of tso_bytes, so remove the subtraction from header size. Cc: stable(a)vger.kernel.org Fixes: bd7fc6e1957c ("net: mana: Add new MANA VF performance counters for easier troubleshooting") Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com> Reviewed-by: Simon Horman <horms(a)kernel.org> --- drivers/net/ethernet/microsoft/mana/mana_en.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c index 5cdcf7561b38..86e724c3eb89 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -264,8 +264,6 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev) ihs = skb_transport_offset(skb) + sizeof(struct udphdr); } else { ihs = skb_tcp_all_headers(skb); - if (ipv6_has_hopopt_jumbo(skb)) - ihs -= sizeof(struct hop_jumbo_hdr); } u64_stats_update_begin(&tx_stats->syncp); -- 2.25.1

1 year, 6 months

2
1
0 0

[tip: x86/platform] x86/amd_nb: Use Family 19h Models 60h-7Fh Function 4 IDs

by tip-bot2 for Yazen Ghannam

The following commit has been merged into the x86/platform branch of tip: Commit-ID: 2a565258b3f4bbdc7a3c09cd02082cb286a7bffc Gitweb: https://git.kernel.org/tip/2a565258b3f4bbdc7a3c09cd02082cb286a7bffc Author: Yazen Ghannam <yazen.ghannam(a)amd.com> AuthorDate: Thu, 03 Aug 2023 10:04:30 -05:00 Committer: Ingo Molnar <mingo(a)kernel.org> CommitterDate: Tue, 03 Oct 2023 11:25:01 +02:00 x86/amd_nb: Use Family 19h Models 60h-7Fh Function 4 IDs Three PCI IDs for DF Function 4 were defined but not used. Add them to the "link" list. Fixes: f8faf3496633 ("x86/amd_nb: Add AMD PCI IDs for SMN communication") Fixes: 23a5b8bb022c ("x86/amd_nb: Add PCI ID for family 19h model 78h") Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20230803150430.3542854-1-yazen.ghannam@amd.com --- arch/x86/kernel/amd_nb.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c index 10c2a3c..43238ac 100644 --- a/arch/x86/kernel/amd_nb.c +++ b/arch/x86/kernel/amd_nb.c @@ -116,6 +116,9 @@ static const struct pci_device_id amd_nb_link_ids[] = { { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M10H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M40H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M50H_DF_F4) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M60H_DF_F4) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M70H_DF_F4) }, + { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_M78H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_1AH_M00H_DF_F4) }, { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_MI200_DF_F4) },

1 year, 6 months

1
0
0 0

[PATCH v2 2/2] arm64: dts: mt7986: fix emmc hs400 mode without uboot initialization

by Frank Wunderlich

From: Eric Woudstra <ericwouds(a)gmail.com> Eric reports errors on emmc with hs400 mode when booting linux on bpi-r3 without uboot [1]. Booting with uboot does not show this because clocks seem to be initialized by uboot. Fix this by adding assigned-clocks and assigned-clock-parents like it's done in uboot [2]. [1] https://forum.banana-pi.org/t/bpi-r3-kernel-fails-setting-emmc-clock-to-416… [2] https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/mt7986.dtsi#L287 Cc: stable(a)vger.kernel.org Fixes: 513b49d19b34 ("arm64: dts: mt7986: add mmc related device nodes") Signed-off-by: Eric Woudstra <ericwouds(a)gmail.com> Signed-off-by: Frank Wunderlich <frank-w(a)public-files.de> --- arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi index 68539ea788df..207510abda89 100644 --- a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi @@ -374,6 +374,10 @@ mmc0: mmc@11230000 { reg = <0 0x11230000 0 0x1000>, <0 0x11c20000 0 0x1000>; interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>; + assigned-clocks = <&topckgen CLK_TOP_EMMC_416M_SEL>, + <&topckgen CLK_TOP_EMMC_250M_SEL>; + assigned-clock-parents = <&apmixedsys CLK_APMIXED_MPLL>, + <&topckgen CLK_TOP_NET1PLL_D5_D2>; clocks = <&topckgen CLK_TOP_EMMC_416M_SEL>, <&infracfg CLK_INFRA_MSDC_HCK_CK>, <&infracfg CLK_INFRA_MSDC_CK>, -- 2.34.1

1 year, 6 months

3
2
0 0

[PULL 01/24] optionrom: Remove build-id section

by Paolo Bonzini

From: Fabiano Rosas <farosas(a)suse.de> Our linker script for optionroms specifies only the placement of the .text section, leaving the linker free to place the remaining sections at arbitrary places in the file. Since at least binutils 2.39, the .note.gnu.build-id section is now being placed at the start of the file, which causes label addresses to be shifted. For linuxboot_dma.bin that means that the PnP header (among others) will not be found when determining the type of ROM at optionrom_setup(): (0x1c is the label _pnph, where the magic "PnP" is) $ xxd /usr/share/qemu/linuxboot_dma.bin | grep "PnP" 00000010: 0000 0000 0000 0000 0000 1c00 2450 6e50 ............$PnP $ xxd pc-bios/optionrom/linuxboot_dma.bin | grep "PnP" 00000010: 0000 0000 0000 0000 0000 4c00 2450 6e50 ............$PnP ^bad Using a freshly built linuxboot_dma.bin ROM results in a broken boot: SeaBIOS (version rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org) Booting from Hard Disk... Boot failed: could not read the boot disk Booting from Floppy... Boot failed: could not read the boot disk No bootable device. We're not using the build-id section, so pass the --build-id=none option to the linker to remove it entirely. Note: In theory, this same issue could happen with any other section. The ideal solution would be to have all unused sections discarded in the linker script. However that would be a larger change, specially for the pvh rom which uses the .bss and COMMON sections so I'm addressing only the immediate issue here. Reported-by: Vasiliy Ulyanov <vulyanov(a)suse.de> Signed-off-by: Fabiano Rosas <farosas(a)suse.de> Reviewed-by: Thomas Huth <thuth(a)redhat.com> Message-ID: <20230926192502.15986-1-farosas(a)suse.de> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- pc-bios/optionrom/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile index b1fff0ba6c8..30d07026c79 100644 --- a/pc-bios/optionrom/Makefile +++ b/pc-bios/optionrom/Makefile @@ -36,7 +36,7 @@ config-cc.mak: Makefile $(call cc-option,-Wno-array-bounds)) 3> config-cc.mak -include config-cc.mak -override LDFLAGS = -nostdlib -Wl,-T,$(SRC_DIR)/flat.lds +override LDFLAGS = -nostdlib -Wl,--build-id=none,-T,$(SRC_DIR)/flat.lds pvh.img: pvh.o pvh_main.o -- 2.41.0

1 year, 6 months

1
0
0 0

Letter of Intent (LOI) (03-10-2023)

by Ahmad R Deeb

Attn: stable(a)vger.kernel.org Date: 03-10-2023 Subject: Letter of Intent (LOI) (03-10-2023) This is a Letter of Intent concerning my Board of investors intent to fund some of your available investment projects. If this is of any interest to you then kindly advise. Yours Faithfully, Ahmad R. Deeb Head of Investment Team

1 year, 6 months

1
0
0 0

[PATCH v2 1/4] x86: KVM: SVM: always update the x2avic msr interception

by Maxim Levitsky

The following problem exists since x2avic was enabled in the KVM: svm_set_x2apic_msr_interception is called to enable the interception of the x2apic msrs. In particular it is called at the moment the guest resets its apic. Assuming that the guest's apic was in x2apic mode, the reset will bring it back to the xapic mode. The svm_set_x2apic_msr_interception however has an erroneous check for '!apic_x2apic_mode()' which prevents it from doing anything in this case. As a result of this, all x2apic msrs are left unintercepted, and that exposes the bare metal x2apic (if enabled) to the guest. Oops. Remove the erroneous '!apic_x2apic_mode()' check to fix that. This fixes CVE-2023-5090 Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode") Cc: stable(a)vger.kernel.org Signed-off-by: Maxim Levitsky <mlevitsk(a)redhat.com> --- arch/x86/kvm/svm/svm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 9507df93f410a63..acdd0b89e4715a3 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -913,8 +913,7 @@ void svm_set_x2apic_msr_interception(struct vcpu_svm *svm, bool intercept) if (intercept == svm->x2avic_msrs_intercepted) return; - if (!x2avic_enabled || - !apic_x2apic_mode(svm->vcpu.arch.apic)) + if (!x2avic_enabled) return; for (i = 0; i < MAX_DIRECT_ACCESS_MSRS; i++) { -- 2.26.3

1 year, 6 months

3
2
0 0

[PATCH] rcu: kmemleak: Ignore kmemleak false positives when RCU-freeing objects

by Joel Fernandes (Google)

From: Catalin Marinas <catalin.marinas(a)arm.com> Since the actual slab freeing is deferred when calling kvfree_rcu(), so is the kmemleak_free() callback informing kmemleak of the object deletion. From the perspective of the kvfree_rcu() caller, the object is freed and it may remove any references to it. Since kmemleak does not scan RCU internal data storing the pointer, it will report such objects as leaks during the grace period. Tell kmemleak to ignore such objects on the kvfree_call_rcu() path. Note that the tiny RCU implementation does not have such issue since the objects can be tracked from the rcu_ctrlblk structure. Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> Reported-by: Christoph Paasch <cpaasch(a)apple.com> Closes: https://lore.kernel.org/all/F903A825-F05F-4B77-A2B5-7356282FBA2C@apple.com/ Cc: <stable(a)vger.kernel.org> Tested-by: Christoph Paasch <cpaasch(a)apple.com> Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> --- kernel/rcu/tree.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index cb1caefa8bd0..24423877962c 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -31,6 +31,7 @@ #include <linux/bitops.h> #include <linux/export.h> #include <linux/completion.h> +#include <linux/kmemleak.h> #include <linux/moduleparam.h> #include <linux/panic.h> #include <linux/panic_notifier.h> @@ -3388,6 +3389,14 @@ void kvfree_call_rcu(struct rcu_head *head, void *ptr) success = true; } + /* + * The kvfree_rcu() caller considers the pointer freed at this point + * and likely removes any references to it. Since the actual slab + * freeing (and kmemleak_free()) is deferred, tell kmemleak to ignore + * this object (no scanning or false positives reporting). + */ + kmemleak_ignore(ptr); + // Set timer to drain after KFREE_DRAIN_JIFFIES. if (rcu_scheduler_active == RCU_SCHEDULER_RUNNING) schedule_delayed_monitor_work(krcp); -- 2.42.0.582.g8ccd20d70d-goog

1 year, 6 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2023