September 2023 - Linux-stable-mirror

[PATCH v5] block: add check that partition length needs to be aligned with block size

by Min Li

Before calling add partition or resize partition, there is no check on whether the length is aligned with the logical block size. If the logical block size of the disk is larger than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the last sector is read, bio_truncate() will adjust the bio size, resulting in an IO error if the size of the read command is smaller than the logical block size.If integrity data is supported, this will also result in a null pointer dereference when calling bio_integrity_free. Cc: stable(a)vger.kernel.org Signed-off-by: Min Li <min15.li(a)samsung.com> Reviewed-by: Damien Le Moal <dlemoal(a)kernel.org> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> --- Changes from v1: - Add a space after /* and before */. - Move length alignment check before the "start = p.start >> SECTOR_SHIFT" - Move check for p.start being aligned together with this length alignment check. Changes from v2: - Add the assignment on the first line and merge the two lines into one. Changes from v3: - Change the blksz to unsigned int. - Add check if p.start and p.length are negative. Changes from v4: - Remove the local variable blksz and use bdev_logical_block_size(bdev) directly. --- block/ioctl.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/block/ioctl.c b/block/ioctl.c index 3be11941fb2d..0e8723c1a807 100644 --- a/block/ioctl.c +++ b/block/ioctl.c @@ -18,7 +18,7 @@ static int blkpg_do_ioctl(struct block_device *bdev, { struct gendisk *disk = bdev->bd_disk; struct blkpg_partition p; - long long start, length; + sector_t start, length; if (!capable(CAP_SYS_ADMIN)) return -EACCES; @@ -33,14 +33,17 @@ static int blkpg_do_ioctl(struct block_device *bdev, if (op == BLKPG_DEL_PARTITION) return bdev_del_partition(disk, p.pno); + if (p.start < 0 || p.length <= 0 || p.start + p.length < 0) + return -EINVAL; + /* Check that the partition is aligned to the block size */ + if (!IS_ALIGNED(p.start | p.length, bdev_logical_block_size(bdev))) + return -EINVAL; + start = p.start >> SECTOR_SHIFT; length = p.length >> SECTOR_SHIFT; switch (op) { case BLKPG_ADD_PARTITION: - /* check if partition is aligned to blocksize */ - if (p.start & (bdev_logical_block_size(bdev) - 1)) - return -EINVAL; return bdev_add_partition(disk, p.pno, start, length); case BLKPG_RESIZE_PARTITION: return bdev_resize_partition(disk, p.pno, start, length); -- 2.34.1

1 year, 11 months

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

2 years

10
29
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 years

3
13
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

2 years

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

2 years

7
6
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 years

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

2 years, 1 month

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

2 years, 1 month

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

2 years, 1 month

7
9
0 0

[PATCH] sbsa_gwdt: Calculate timeout with 64-bit math

by Darren Hart

Commit abd3ac7902fb ("watchdog: sbsa: Support architecture version 1") introduced new timer math for watchdog revision 1 with the 48 bit offset register. The gwdt->clk and timeout are u32, but the argument being calculated is u64. Without a cast, the compiler performs u32 operations, truncating intermediate steps, resulting in incorrect values. A watchdog revision 1 implementation with a gwdt->clk of 1GHz and a timeout of 600s writes 3647256576 to the one shot watchdog instead of 300000000000, resulting in the watchdog firing in 3.6s instead of 600s. Force u64 math by casting the first argument (gwdt->clk) as a u64. Make the order of operations explicit with parenthesis. Fixes: abd3ac7902fb ("watchdog: sbsa: Support architecture version 1") Reported-by: Vanshidhar Konda <vanshikonda(a)os.amperecomputing.com> Signed-off-by: Darren Hart <darren(a)os.amperecomputing.com> Cc: Wim Van Sebroeck <wim(a)linux-watchdog.org> Cc: Guenter Roeck <linux(a)roeck-us.net> Cc: linux-watchdog(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: <stable(a)vger.kernel.org> # 5.14.x --- drivers/watchdog/sbsa_gwdt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c index fd3cfdda4949..76527324b63c 100644 --- a/drivers/watchdog/sbsa_gwdt.c +++ b/drivers/watchdog/sbsa_gwdt.c @@ -153,14 +153,14 @@ static int sbsa_gwdt_set_timeout(struct watchdog_device *wdd, timeout = clamp_t(unsigned int, timeout, 1, wdd->max_hw_heartbeat_ms / 1000); if (action) - sbsa_gwdt_reg_write(gwdt->clk * timeout, gwdt); + sbsa_gwdt_reg_write((u64)gwdt->clk * timeout, gwdt); else /* * In the single stage mode, The first signal (WS0) is ignored, * the timeout is (WOR * 2), so the WOR should be configured * to half value of timeout. */ - sbsa_gwdt_reg_write(gwdt->clk / 2 * timeout, gwdt); + sbsa_gwdt_reg_write(((u64)gwdt->clk / 2) * timeout, gwdt); return 0; } -- 2.41.0

2 years, 1 month

3
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2023