September 2023 - Linux-stable-mirror

[PATCH] ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on action required events

by Shuai Xue

There are two major types of uncorrected error (UC) : - Action Required: The error is detected and the processor already consumes the memory. OS requires to take action (for example, offline failure page/kill failure thread) to recover this uncorrectable error. - Action Optional: The error is detected out of processor execution context. Some data in the memory are corrupted. But the data have not been consumed. OS is optional to take action to recover this uncorrectable error. For X86 platforms, we can easily distinguish between these two types based on the MCA Bank. While for arm64 platform, the memory failure flags for all UCs which severity are GHES_SEV_RECOVERABLE are set as 0, a.k.a, Action Optional now. If UC is detected by a background scrubber, it is obviously an Action Optional error. For other errors, we should conservatively regard them as Action Required. cper_sec_mem_err::error_type identifies the type of error that occurred if CPER_MEM_VALID_ERROR_TYPE is set. So, set memory failure flags as 0 for Scrub Uncorrected Error (type 14). Otherwise, set memory failure flags as MF_ACTION_REQUIRED. Signed-off-by: Shuai Xue <xueshuai(a)linux.alibaba.com> --- drivers/acpi/apei/ghes.c | 10 ++++++++-- include/linux/cper.h | 3 +++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index 80ad530583c9..6c03059cbfc6 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -474,8 +474,14 @@ static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, if (sec_sev == GHES_SEV_CORRECTED && (gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED)) flags = MF_SOFT_OFFLINE; - if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE) - flags = 0; + if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE) { + if (mem_err->validation_bits & CPER_MEM_VALID_ERROR_TYPE) + flags = mem_err->error_type == CPER_MEM_SCRUB_UC ? + 0 : + MF_ACTION_REQUIRED; + else + flags = MF_ACTION_REQUIRED; + } if (flags != -1) return ghes_do_memory_failure(mem_err->physical_addr, flags); diff --git a/include/linux/cper.h b/include/linux/cper.h index eacb7dd7b3af..b77ab7636614 100644 --- a/include/linux/cper.h +++ b/include/linux/cper.h @@ -235,6 +235,9 @@ enum { #define CPER_MEM_VALID_BANK_ADDRESS 0x100000 #define CPER_MEM_VALID_CHIP_ID 0x200000 +#define CPER_MEM_SCRUB_CE 13 +#define CPER_MEM_SCRUB_UC 14 + #define CPER_MEM_EXT_ROW_MASK 0x3 #define CPER_MEM_EXT_ROW_SHIFT 16 -- 2.20.1.9.gb50a0d7

8 minutes

8
30
0 0

[PATCH 0/4] cpufreq: Add basic cpufreq scaling for Qualcomm MSM8909

by Stephan Gerhold

Add the necessary definitions to the qcom-cpufreq-nvmem driver to support basic cpufreq scaling on the Qualcomm MSM8909 SoC. In practice the necessary power domains vary depending on the actual PMIC the SoC was combined with. With PM8909 the VDD_APC power domain is shared with VDD_CX so the RPM firmware handles all voltage adjustments, while with PM8916 and PM660 Linux is responsible to do adaptive voltage scaling of a dedicated CPU regulator using CPR. Signed-off-by: Stephan Gerhold <stephan.gerhold(a)kernkonzept.com> --- Stephan Gerhold (4): cpufreq: qcom-nvmem: Enable virtual power domain devices cpufreq: dt: platdev: Add MSM8909 to blocklist dt-bindings: cpufreq: qcom-nvmem: Document MSM8909 cpufreq: qcom-nvmem: Add MSM8909 .../bindings/cpufreq/qcom-cpufreq-nvmem.yaml | 1 + drivers/cpufreq/cpufreq-dt-platdev.c | 1 + drivers/cpufreq/qcom-cpufreq-nvmem.c | 47 +++++++++++++++++++++- 3 files changed, 48 insertions(+), 1 deletion(-) --- base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d change-id: 20230906-msm8909-cpufreq-dff238de9ff3 Best regards, -- Stephan Gerhold <stephan.gerhold(a)kernkonzept.com> Kernkonzept GmbH at Dresden, Germany, HRB 31129, CEO Dr.-Ing. Michael Hohmuth

2 days, 5 hours

3
12
0 0

Fwd: dwc3: regression in USB DWC3 driver in kernel 5.15 branch

by Bagas Sanjaya

Hi, I notice a stable-specific regression on Bugzilla [1]. Quoting from it: > The backport commit to 5.15 branch: > 9d4f84a15f9c9727bc07f59d9dafc89e65aadb34 "arm64: dts: imx8mp: Add snps,gfladj-refclk-lpm-sel quirk to USB nodes" (from upstream commit 5c3d5ecf48ab06c709c012bf1e8f0c91e1fcd7ad) > switched from "snps,dis-u2-freeclk-exists-quirk" to "snps,gfladj-refclk-lpm-sel-quirk". > > The problem is that the gfladj-refclk-lpm-sel-quirk quirk is not implemented / backported to 5.15 branch. > > This commit should be either reverted, or the commit introducing gfladj-refclk-lpm-sel-quirk needs to be merged to 5.15 kernel branch. > > As a result of this patch, on Gateworks Venice GW7400 revB board the USB 3.x devices which are connected to the USB Type C port does not enumerate and the following errors are generated: > > [ 14.906302] xhci-hcd xhci-hcd.0.auto: Timeout while waiting for setup device command > [ 15.122383] usb 2-1: device not accepting address 2, error -62 > [ 25.282195] xhci-hcd xhci-hcd.0.auto: Abort failed to stop command ring: -110 > [ 25.297408] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead > [ 25.305345] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up > [ 25.311058] xhci-hcd xhci-hcd.0.auto: Timeout while waiting for stop endpoint command > [ 25.334361] usb usb2-port1: couldn't allocate usb_device > > When the commit is reverted the USB 3.x drives works fine. See Bugzilla for the full thread and attach dmesgs. Anyway, I'm adding it to regzbot: #regzbot introduced: 9d4f84a15f9c97 https://bugzilla.kernel.org/show_bug.cgi?id=217670 #regzbot title: regression in USB DWC3 driver due to missing gfladj-refclk-lpm-sel-quirk quirk Thanks. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217670 -- An old man doll... just what I always wanted! - Clara

6 days, 1 hour

4
4
0 0

[PATCH v4] aacraid: reply queue mapping to CPUs based of IRQ affinity

by Sagar Biradar

Fix the IO hang that arises because of MSIx vector not having a mapped online CPU upon receiving completion. The SCSI cmds take the blk_mq route, which is setup during the init. The reserved cmds fetch the vector_no from mq_map after the init is complete and before the init, they use 0 - as per the norm. Reviewed-by: Gilbert Wu <gilbert.wu(a)microchip.com> Signed-off-by: Sagar Biradar <Sagar.Biradar(a)microchip.com> --- drivers/scsi/aacraid/aacraid.h | 1 + drivers/scsi/aacraid/comminit.c | 1 - drivers/scsi/aacraid/commsup.c | 6 +++++- drivers/scsi/aacraid/linit.c | 14 ++++++++++++++ drivers/scsi/aacraid/src.c | 25 +++++++++++++++++++++++-- 5 files changed, 43 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/aacraid/aacraid.h b/drivers/scsi/aacraid/aacraid.h index 5e115e8b2ba4..7c6efde75da6 100644 --- a/drivers/scsi/aacraid/aacraid.h +++ b/drivers/scsi/aacraid/aacraid.h @@ -1678,6 +1678,7 @@ struct aac_dev u32 handle_pci_error; bool init_reset; u8 soft_reset_support; + u8 use_map_queue; }; #define aac_adapter_interrupt(dev) \ diff --git a/drivers/scsi/aacraid/comminit.c b/drivers/scsi/aacraid/comminit.c index bd99c5492b7d..a5483e7e283a 100644 --- a/drivers/scsi/aacraid/comminit.c +++ b/drivers/scsi/aacraid/comminit.c @@ -657,4 +657,3 @@ struct aac_dev *aac_init_adapter(struct aac_dev *dev) return dev; } - diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c index deb32c9f4b3e..3f062e4013ab 100644 --- a/drivers/scsi/aacraid/commsup.c +++ b/drivers/scsi/aacraid/commsup.c @@ -223,8 +223,12 @@ int aac_fib_setup(struct aac_dev * dev) struct fib *aac_fib_alloc_tag(struct aac_dev *dev, struct scsi_cmnd *scmd) { struct fib *fibptr; + u32 blk_tag; + int i; - fibptr = &dev->fibs[scsi_cmd_to_rq(scmd)->tag]; + blk_tag = blk_mq_unique_tag(scsi_cmd_to_rq(scmd)); + i = blk_mq_unique_tag_to_tag(blk_tag); + fibptr = &dev->fibs[i]; /* * Null out fields that depend on being zero at the start of * each I/O diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c index 5ba5c18b77b4..9caf8c314ce1 100644 --- a/drivers/scsi/aacraid/linit.c +++ b/drivers/scsi/aacraid/linit.c @@ -19,6 +19,7 @@ #include <linux/compat.h> #include <linux/blkdev.h> +#include <linux/blk-mq-pci.h> #include <linux/completion.h> #include <linux/init.h> #include <linux/interrupt.h> @@ -505,6 +506,15 @@ static int aac_slave_configure(struct scsi_device *sdev) return 0; } +static void aac_map_queues(struct Scsi_Host *shost) +{ + struct aac_dev *aac = (struct aac_dev *)shost->hostdata; + + blk_mq_pci_map_queues(&shost->tag_set.map[HCTX_TYPE_DEFAULT], + aac->pdev, 0); + aac->use_map_queue = true; +} + /** * aac_change_queue_depth - alter queue depths * @sdev: SCSI device we are considering @@ -1489,6 +1499,7 @@ static struct scsi_host_template aac_driver_template = { .bios_param = aac_biosparm, .shost_groups = aac_host_groups, .slave_configure = aac_slave_configure, + .map_queues = aac_map_queues, .change_queue_depth = aac_change_queue_depth, .sdev_groups = aac_dev_groups, .eh_abort_handler = aac_eh_abort, @@ -1776,6 +1787,8 @@ static int aac_probe_one(struct pci_dev *pdev, const struct pci_device_id *id) shost->max_lun = AAC_MAX_LUN; pci_set_drvdata(pdev, shost); + shost->nr_hw_queues = aac->max_msix; + shost->host_tagset = 1; error = scsi_add_host(shost, &pdev->dev); if (error) @@ -1908,6 +1921,7 @@ static void aac_remove_one(struct pci_dev *pdev) struct aac_dev *aac = (struct aac_dev *)shost->hostdata; aac_cancel_rescan_worker(aac); + aac->use_map_queue = false; scsi_remove_host(shost); __aac_shutdown(aac); diff --git a/drivers/scsi/aacraid/src.c b/drivers/scsi/aacraid/src.c index 11ef58204e96..61949f374188 100644 --- a/drivers/scsi/aacraid/src.c +++ b/drivers/scsi/aacraid/src.c @@ -493,6 +493,10 @@ static int aac_src_deliver_message(struct fib *fib) #endif u16 vector_no; + struct scsi_cmnd *scmd; + u32 blk_tag; + struct Scsi_Host *shost = dev->scsi_host_ptr; + struct blk_mq_queue_map *qmap; atomic_inc(&q->numpending); @@ -505,8 +509,25 @@ static int aac_src_deliver_message(struct fib *fib) if ((dev->comm_interface == AAC_COMM_MESSAGE_TYPE3) && dev->sa_firmware) vector_no = aac_get_vector(dev); - else - vector_no = fib->vector_no; + else { + if (!fib->vector_no || !fib->callback_data) { + if (shost && dev->use_map_queue) { + qmap = &shost->tag_set.map[HCTX_TYPE_DEFAULT]; + vector_no = qmap->mq_map[raw_smp_processor_id()]; + } + /* + * We hardcode the vector_no for + * reserved commands as a valid shost is + * absent during the init + */ + else + vector_no = 0; + } else { + scmd = (struct scsi_cmnd *)fib->callback_data; + blk_tag = blk_mq_unique_tag(scsi_cmd_to_rq(scmd)); + vector_no = blk_mq_unique_tag_to_hwq(blk_tag); + } + } if (native_hba) { if (fib->flags & FIB_CONTEXT_FLAG_NATIVE_HBA_TMF) { -- 2.29.0

6 days, 11 hours

7
6
0 0

[PATCH v7 0/5] mfd: tps6586x: register restart handler

by Benjamin Bara

Hi! The Tegra20 requires an enabled VDE power domain during startup. As the VDE is currently not used, it is disabled during runtime. Since 8f0c714ad9be, there is a workaround for the "normal restart path" which enables the VDE before doing PMC's warm reboot. This workaround is not executed in the "emergency restart path", leading to a hang-up during start. This series implements and registers a new pmic-based restart handler for boards with tps6586x. This cold reboot ensures that the VDE power domain is enabled during startup on tegra20-based boards. Since bae1d3a05a8b, i2c transfers are non-atomic while preemption is disabled (which is e.g. done during panic()). This could lead to warnings ("Voluntary context switch within RCU") in i2c-based restart handlers during emergency restart. The state of preemption should be detected by i2c_in_atomic_xfer_mode() to use atomic i2c xfer when required. Beside the new system_state check, the check is the same as the one pre v5.2. --- v7: - 5/5: drop mode check (suggested by Dmitry) - Link to v6: https://lore.kernel.org/r/20230327-tegra-pmic-reboot-v6-0-af44a4cd82e9@skid… v6: - drop 4/6 to abort restart on unexpected failure (suggested by Dmitry) - 4,5: fix comments in handlers (suggested by Lee) - 4,5: same delay for both handlers (suggested by Lee) v5: - introduce new 3 & 4, therefore 3 -> 5, 4 -> 6 - 3: provide dev to sys_off handler, if it is known - 4: return NOTIFY_DONE from sys_off_notify, to avoid skipping - 5: drop Reviewed-by from Dmitry, add poweroff timeout - 5,6: return notifier value instead of direct errno from handler - 5,6: use new dev field instead of passing dev as cb_data - 5,6: increase timeout values based on error observations - 6: skip unsupported reboot modes in restart handler --- Benjamin Bara (5): kernel/reboot: emergency_restart: set correct system_state i2c: core: run atomic i2c xfer when !preemptible kernel/reboot: add device to sys_off_handler mfd: tps6586x: use devm-based power off handler mfd: tps6586x: register restart handler drivers/i2c/i2c-core.h | 2 +- drivers/mfd/tps6586x.c | 50 ++++++++++++++++++++++++++++++++++++++++++-------- include/linux/reboot.h | 3 +++ kernel/reboot.c | 4 ++++ 4 files changed, 50 insertions(+), 9 deletions(-) --- base-commit: 197b6b60ae7bc51dd0814953c562833143b292aa change-id: 20230327-tegra-pmic-reboot-4175ff814a4b Best regards, -- Benjamin Bara <benjamin.bara(a)skidata.com>

2 weeks, 1 day

5
14
0 0

[PATCH v2] iio: cros_ec: fix an use-after-free in cros_ec_sensors_push_data()

by Tzung-Bi Shih

cros_ec_sensors_push_data() reads `indio_dev->active_scan_mask` and calls iio_push_to_buffers_with_timestamp() without making sure the `indio_dev` stays in buffer mode. There is a race if `indio_dev` exits buffer mode right before cros_ec_sensors_push_data() accesses them. An use-after-free on `indio_dev->active_scan_mask` was observed. The call trace: [...] _find_next_bit cros_ec_sensors_push_data cros_ec_sensorhub_event blocking_notifier_call_chain cros_ec_irq_thread It was caused by a race condition: one thread just freed `active_scan_mask` at [1]; while another thread tried to access the memory at [2]. Fix it by calling iio_device_claim_buffer_mode() to ensure the `indio_dev` can't exit buffer mode during cros_ec_sensors_push_data(). [1]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/industrialio-buffe… [2]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/common/cros_ec_sen… Cc: stable(a)vger.kernel.org Fixes: aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO") Signed-off-by: Tzung-Bi Shih <tzungbi(a)kernel.org> --- Changes from v1(https://patchwork.kernel.org/project/linux-iio/patch/20230828094339.1248…: - Use iio_device_{claim|release}_buffer_mode() instead of accessing `mlock`. drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c index b72d39fc2434..6bfe5d6847e7 100644 --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c @@ -190,8 +190,11 @@ int cros_ec_sensors_push_data(struct iio_dev *indio_dev, /* * Ignore samples if the buffer is not set: it is needed if the ODR is * set but the buffer is not enabled yet. + * + * Note: iio_device_claim_buffer_mode() returns -EBUSY if the buffer + * is not enabled. */ - if (!iio_buffer_enabled(indio_dev)) + if (iio_device_claim_buffer_mode(indio_dev) < 0) return 0; out = (s16 *)st->samples; @@ -210,6 +213,7 @@ int cros_ec_sensors_push_data(struct iio_dev *indio_dev, iio_push_to_buffers_with_timestamp(indio_dev, st->samples, timestamp + delta); + iio_device_release_buffer_mode(indio_dev); return 0; } EXPORT_SYMBOL_GPL(cros_ec_sensors_push_data); -- 2.42.0.rc2.253.gd59a3bf2b4-goog

2 weeks, 3 days

5
5
0 0

[RESEND PATCH] Revert "fuse: Apply flags2 only when userspace set the FUSE_INIT_EXT"

by André Draszik

From: André Draszik <andre.draszik(a)linaro.org> This reverts commit 3066ff93476c35679cb07a97cce37d9bb07632ff. This patch breaks all existing userspace by requiring updates as mentioned in the commit message, which is not allowed. Revert to restore compatibility with existing userspace implementations. Cc: Bernd Schubert <bschubert(a)ddn.com> Cc: Miklos Szeredi <mszeredi(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: André Draszik <andre.draszik(a)linaro.org> --- resend because of missing people in Cc --- fs/fuse/inode.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c index 549358ffea8b..0b966b0e0962 100644 --- a/fs/fuse/inode.c +++ b/fs/fuse/inode.c @@ -1132,10 +1132,7 @@ static void process_init_reply(struct fuse_mount *fm, struct fuse_args *args, process_init_limits(fc, arg); if (arg->minor >= 6) { - u64 flags = arg->flags; - - if (flags & FUSE_INIT_EXT) - flags |= (u64) arg->flags2 << 32; + u64 flags = arg->flags | (u64) arg->flags2 << 32; ra_pages = arg->max_readahead / PAGE_SIZE; if (flags & FUSE_ASYNC_READ) -- 2.40.1

3 weeks, 1 day

10
28
0 0

[PATCH] riscv: kprobes: allow writing to x0

by Nam Cao

Instructions can write to x0, so we should simulate these instructions normally. Currently, the kernel hangs if an instruction who writes to x0 is simulated. Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported") Cc: stable(a)vger.kernel.org Signed-off-by: Nam Cao <namcaov(a)gmail.com> --- arch/riscv/kernel/probes/simulate-insn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/kernel/probes/simulate-insn.c b/arch/riscv/kernel/probes/simulate-insn.c index d3099d67816d..6c166029079c 100644 --- a/arch/riscv/kernel/probes/simulate-insn.c +++ b/arch/riscv/kernel/probes/simulate-insn.c @@ -24,7 +24,7 @@ static inline bool rv_insn_reg_set_val(struct pt_regs *regs, u32 index, unsigned long val) { if (index == 0) - return false; + return true; else if (index <= 31) *((unsigned long *)regs + index) = val; else -- 2.34.1

3 weeks, 3 days

4
3
0 0

Fwd: System (Xeon Nvidia) hangs at boot terminal after kernel 6.4.7

by Bagas Sanjaya

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > Kernel 6.4.6 compiled from source worked AOK on my desktop with Intel Xeon cpu and Nvidia graphics - see below for system specs. > > Kernels 6.4.7 & 6.4.8 also compiled from source with identical configs hang with a frozen boot terminal screen after a significant way through the boot sequence (e.g. whilst running /etc/profile). The system may still be running as a sound is emitted when the power button is pressed (only way to escape from the system hang). > > The issue seems to be specific to the hardware of this desktop as the problem kernels do boot through to completion on other machines. > > A test was done with a different build (from Porteus) of kernel 6.5-RC4 and that did not hang - but kernel 6.4.7 from the same builder hung just like my build. > > I apologise that I cannot provide any detailed diagnostics - but I can put diagnostics into /etc/profile and provide screenshots if requested. > > Forum thread with more details and screenshots: > https://forum.puppylinux.com/viewtopic.php?p=95733#p95733 > > Computer Profile: > Machine Dell Inc. Precision WorkStation T5400 (version: Not Specified) > Mainboard Dell Inc. 0RW203 (version: NA) > • BIOS Dell Inc. A11 | Date: 04/30/2012 | Type: Legacy > • CPU Intel(R) Xeon(R) CPU E5450 @ 3.00GHz (4 cores) > • RAM Total: 7955 MB | Used: 1555 MB (19.5%) | Actual Used: 775 MB (9.7%) > Graphics Resolution: 1366x768 pixels | Display Server: X.Org 21.1.8 > • device-0 NVIDIA Corporation GT218 [NVS 300] [10de:10d8] (rev a2) > Audio ALSA > • device-0 Intel Corporation 631xESB/632xESB High Definition Audio Controller [8086:269a] (rev 09) > • device-1 NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1) > Network wlan1 > • device-0 Ethernet: Broadcom Inc. and subsidiaries NetXtreme BCM5754 Gigabit Ethernet PCI Express [14e4:167a] (rev 02) See Bugzilla for the full thread. FYI, this is stable-specific regression since it doesn't appear on mainline. Also, I have asked the reporter to also open the issue on gitlab.freedesktop.org tracker (as it is the standard for DRM subsystem). To the reporter (on To: list): It'd been great if you also have netconsole output on your Bugzilla report, providing that you have another machine connecting to your problematic one. Anyway, I'm adding this regression to be tracked by regzbot: #regzbot introduced: v6.4.6..v6.4.7 https://bugzilla.kernel.org/show_bug.cgi?id=217776 #regzbot link: https://forum.puppylinux.com/viewtopic.php?p=95733#p95733 Thanks. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217776 -- An old man doll... just what I always wanted! - Clara

4 weeks, 1 day

3
2
0 0

Fwd: WARNING: CPU: 13 PID: 3837105 at kernel/sched/sched.h:1561 __cfsb_csd_unthrottle+0x149/0x160

by Bagas Sanjaya

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > Hello, we recently got a few kernel crashes with following backtrace. Happened on 6.4.12 (and 6.4.11 I think) but did not happen (I think) on 6.4.4. > > [293790.928007] ------------[ cut here ]------------ > [293790.929905] rq->clock_update_flags & RQCF_ACT_SKIP > [293790.929919] WARNING: CPU: 13 PID: 3837105 at kernel/sched/sched.h:1561 __cfsb_csd_unthrottle+0x149/0x160 > [293790.933694] Modules linked in: xt_owner(E) xt_REDIRECT(E) mptcp_diag(E) xsk_diag(E) raw_diag(E) unix_diag(E) af_packet_diag(E) netlink_diag(E) tcp_diag(E) udp_diag(E) inet_diag(E) rpcsec_gss_krb5(E) auth_rpcgss(E) nfsv4(E) nfs(E) lockd(E) grace(E) fscache(E) netfs(E) nbd(E) rbd(E) libceph(E) dns_resolver(E) xt_set(E) ipt_rpfilter(E) ip_set_hash_ip(E) ip_set_hash_net(E) bpf_preload(E) xt_multiport(E) veth(E) wireguard(E) libchacha20poly1305(E) chacha_x86_64(E) poly1305_x86_64(E) ip6_udp_tunnel(E) udp_tunnel(E) curve25519_x86_64(E) libcurve25519_generic(E) libchacha(E) nf_conntrack_netlink(E) xt_nat(E) xt_statistic(E) xt_addrtype(E) ipt_REJECT(E) nf_reject_ipv4(E) ip_set(E) ip_vs_sh(E) ip_vs_wrr(E) ip_vs_rr(E) ip_vs(E) xt_MASQUERADE(E) nft_chain_nat(E) xt_mark(E) xt_conntrack(E) xt_comment(E) nft_compat(E) nf_tables(E) nfnetlink(E) br_netfilter(E) bridge(E) stp(E) llc(E) iptable_nat(E) nf_nat(E) iptable_filter(E) ip_tables(E) overlay(E) dummy(E) sunrpc(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) > [293790.933738] binfmt_misc(E) tls(E) isofs(E) intel_rapl_msr(E) intel_rapl_common(E) kvm_amd(E) virtio_gpu(E) ccp(E) virtio_dma_buf(E) drm_shmem_helper(E) virtio_net(E) vfat(E) kvm(E) i2c_i801(E) drm_kms_helper(E) net_failover(E) irqbypass(E) syscopyarea(E) fat(E) i2c_smbus(E) failover(E) sysfillrect(E) virtio_balloon(E) sysimgblt(E) drm(E) fuse(E) ext4(E) mbcache(E) jbd2(E) sr_mod(E) cdrom(E) sg(E) ahci(E) libahci(E) crct10dif_pclmul(E) crc32_pclmul(E) polyval_clmulni(E) libata(E) polyval_generic(E) ghash_clmulni_intel(E) sha512_ssse3(E) virtio_blk(E) serio_raw(E) btrfs(E) xor(E) zstd_compress(E) raid6_pq(E) libcrc32c(E) crc32c_intel(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) > [293790.946262] Unloaded tainted modules: edac_mce_amd(E):1 > [293790.956625] CPU: 13 PID: 3837105 Comm: QueryWorker-30f Tainted: G W E 6.4.12-1.gdc.el9.x86_64 #1 > [293790.957963] Hardware name: RDO OpenStack Compute/RHEL, BIOS edk2-20230301gitf80f052277c8-2.el9 03/01/2023 > [293790.959681] RIP: 0010:__cfsb_csd_unthrottle+0x149/0x160 > [293790.960933] Code: 37 fa ff 0f 0b e9 17 ff ff ff 80 3d 41 59 fc 01 00 0f 85 21 ff ff ff 48 c7 c7 98 03 95 9d c6 05 2d 59 fc 01 01 e8 77 37 fa ff <0f> 0b 41 8b 85 88 09 00 00 e9 00 ff ff ff 66 0f 1f 84 00 00 00 00 > [293790.964077] RSP: 0000:ffffb708e7217db8 EFLAGS: 00010086 > [293790.965160] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027 > [293790.966340] RDX: ffff905482c5f708 RSI: 0000000000000001 RDI: ffff905482c5f700 > [293790.967839] RBP: ffff9029bb0e9e00 R08: 0000000000000000 R09: 00000000ffff7fff > [293790.969496] R10: ffffb708e7217c58 R11: ffffffff9e3e2c88 R12: 00000000000317c0 > [293790.970859] R13: ffff903602c317c0 R14: 0000000000000000 R15: ffff905482c726b8 > [293790.972085] FS: 00007ff3b66fe640(0000) GS:ffff905482c40000(0000) knlGS:0000000000000000 > [293790.973678] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [293790.974663] CR2: 00007f16889036c0 CR3: 0000002072e34004 CR4: 0000000000770ee0 > [293790.976108] PKRU: 55555554 > [293790.977048] Call Trace: > [293790.978013] <TASK> > [293790.978678] ? __warn+0x80/0x130 > [293790.979727] ? __cfsb_csd_unthrottle+0x149/0x160 > [293790.980824] ? report_bug+0x195/0x1a0 > [293790.981806] ? handle_bug+0x3c/0x70 > [293790.982884] ? exc_invalid_op+0x14/0x70 > [293790.983837] ? asm_exc_invalid_op+0x16/0x20 > [293790.984626] ? __cfsb_csd_unthrottle+0x149/0x160 > [293790.985599] ? __cfsb_csd_unthrottle+0x149/0x160 > [293790.986583] unregister_fair_sched_group+0x73/0x1d0 > [293790.987682] sched_unregister_group_rcu+0x1a/0x40 > [293790.988752] rcu_do_batch+0x199/0x4d0 > [293790.989643] rcu_core+0x267/0x420 > [293790.990418] __do_softirq+0xc8/0x2ab > [293790.991285] __irq_exit_rcu+0xb9/0xf0 > [293790.992555] sysvec_apic_timer_interrupt+0x3c/0x90 > [293790.993477] asm_sysvec_apic_timer_interrupt+0x16/0x20 > [293790.994171] RIP: 0033:0x7ff4dca91f60 > [293790.994801] Code: 75 15 49 8b f7 c5 f8 77 49 ba 80 6c bf f3 f4 7f 00 00 41 ff d2 eb 0d 4b 89 7c 13 f8 49 83 c2 f8 4d 89 57 70 48 8b c3 c5 f8 77 <48> 83 c4 50 5d 4d 8b 97 08 01 00 00 41 85 02 c3 49 8d 14 fc 8b 7a > [293790.997256] RSP: 002b:00007ff3b66fd190 EFLAGS: 00000246 > [293790.998138] RAX: 0000000655fd6ed0 RBX: 0000000655fd6ed0 RCX: 0000000000000004 > [293790.999184] RDX: 0000000000000000 RSI: 000000066cf4939c RDI: 00007ff4f1180eb7 > [293791.000220] RBP: 0000000000000004 R08: 000000066cf48530 R09: 000000066cf493a8 > [293791.001274] R10: 00000000000007f0 R11: 00007ff3bc00ca80 R12: 0000000000000000 > [293791.002222] R13: 000000066cf49390 R14: 00000000cd9e9272 R15: 00007ff39c033800 > [293791.002966] </TASK> > [293791.003489] ---[ end trace 0000000000000000 ]--- > [293791.004440] ------------[ cut here ]------------ > [293791.005479] rq->clock_update_flags < RQCF_ACT_SKIP > [293791.005493] WARNING: CPU: 0 PID: 3920513 at kernel/sched/sched.h:1496 update_curr+0x162/0x1d0 > > Sadly I don't have more info but hopefully this stacktrace will be enough. > See Bugzilla for the full thread. Anyway, I'm adding this regression to regzbot: #regzbot introduced: ebb83d84e49b54 https://bugzilla.kernel.org/show_bug.cgi?id=217843 Thanks. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217843 -- An old man doll... just what I always wanted! - Clara

4 weeks, 1 day

7
9
0 0

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2023