October 2024 - Linux-stable-mirror

[regression] Regular "cracks" in HDMI sound during playback since backport to 6.1.y for 92afcc310038 ("ALSA: hda: Conditionally use snooping for AMD HDMI")

by Salvatore Bonaccorso

Hi In downstream Debian we got a report from Eric Degenetais, in https://bugs.debian.org/1081833 that after the update to the 6.1.106 based version, there were regular cracks in HDMI sound during playback. Eric was able to bisec the issue down to 92afcc310038ebe5d66c689bb0bf418f5451201c in the v6.1.y series which got applied in 6.1.104. Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081833#47 #regzbot introduced: 92afcc310038ebe5d66c689bb0bf418f5451201c #regzbot link: https://bugs.debian.org/1081833 It should be noted that Eric as well tried more recent stable series as well, in particular did test as well 6.10.6 based version back on 20th september, and the issue was reproducible there as well. Is there anything else we can try to provide? Regards, Salvatore

1 month

3
3
0 0

Missing 6.11-stable patch

by Jens Axboe

Hi, Arguably the most important block stable patch I don't see in the most recent review series sent out, which is odd because it's certainly marked with fixes and a stable tag. It's this one: commit e3accac1a976e65491a9b9fba82ce8ddbd3d2389 Author: Damien Le Moal <dlemoal(a)kernel.org> Date: Tue Sep 17 22:32:31 2024 +0900 block: Fix elv_iosched_local_module handling of "none" scheduler and it really must go into -stable asap as it's fixing a real issue that I've had multiple users email me about. Can we get this added to the current 6.11-stable series so we don't miss another release? It's also quite possible that I'm blind and it is indeed in the queue or already there, but for the life of me I can't see it. -- Jens Axboe

1 month

2
2
0 0

[tip: irq/urgent] irqchip/sifive-plic: Return error code on failure

by tip-bot2 for Charlie Jenkins

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: 6eabf656048d904d961584de2e1d45bc0854f9fb Gitweb: https://git.kernel.org/tip/6eabf656048d904d961584de2e1d45bc0854f9fb Author: Charlie Jenkins <charlie(a)rivosinc.com> AuthorDate: Tue, 03 Sep 2024 16:36:19 -07:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Wed, 02 Oct 2024 15:15:33 +02:00 irqchip/sifive-plic: Return error code on failure Set error to -ENOMEM if kcalloc() fails or if irq_domain_add_linear() fails inside of plic_probe() instead of returning 0. Fixes: 4d936f10ff80 ("irqchip/sifive-plic: Probe plic driver early for Allwinner D1 platform") Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Charlie Jenkins <charlie(a)rivosinc.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Anup Patel <anup(a)brainfault.org> Reviewed-by: Alexandre Ghiti <alexghiti(a)rivosinc.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20240903-correct_error_codes_sifive_plic-v1-1-d… Closes: https://lore.kernel.org/r/202409031122.yBh8HrxA-lkp@intel.com/ --- drivers/irqchip/irq-sifive-plic.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c index 2f6ef5c..0b730e3 100644 --- a/drivers/irqchip/irq-sifive-plic.c +++ b/drivers/irqchip/irq-sifive-plic.c @@ -626,8 +626,10 @@ static int plic_probe(struct fwnode_handle *fwnode) handler->enable_save = kcalloc(DIV_ROUND_UP(nr_irqs, 32), sizeof(*handler->enable_save), GFP_KERNEL); - if (!handler->enable_save) + if (!handler->enable_save) { + error = -ENOMEM; goto fail_cleanup_contexts; + } done: for (hwirq = 1; hwirq <= nr_irqs; hwirq++) { plic_toggle(handler, hwirq, 0); @@ -639,8 +641,10 @@ done: priv->irqdomain = irq_domain_create_linear(fwnode, nr_irqs + 1, &plic_irqdomain_ops, priv); - if (WARN_ON(!priv->irqdomain)) + if (WARN_ON(!priv->irqdomain)) { + error = -ENOMEM; goto fail_cleanup_contexts; + } /* * We can have multiple PLIC instances so setup global state

1 month

1
0
0 0

FAILED: patch "[PATCH] dm-verity: restart or panic on an I/O error" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-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.1.y git checkout FETCH_HEAD git cherry-pick -x e6a3531dd542cb127c8de32ab1e54a48ae19962b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024100247-friction-answering-6c42@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: e6a3531dd542 ("dm-verity: restart or panic on an I/O error") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e6a3531dd542cb127c8de32ab1e54a48ae19962b Mon Sep 17 00:00:00 2001 From: Mikulas Patocka <mpatocka(a)redhat.com> Date: Tue, 24 Sep 2024 15:18:29 +0200 Subject: [PATCH] dm-verity: restart or panic on an I/O error Maxim Suhanov reported that dm-verity doesn't crash if an I/O error happens. In theory, this could be used to subvert security, because an attacker can create sectors that return error with the Write Uncorrectable command. Some programs may misbehave if they have to deal with EIO. This commit fixes dm-verity, so that if "panic_on_corruption" or "restart_on_corruption" was specified and an I/O error happens, the machine will panic or restart. This commit also changes kernel_restart to emergency_restart - kernel_restart calls reboot notifiers and these reboot notifiers may wait for the bio that failed. emergency_restart doesn't call the notifiers. Reported-by: Maxim Suhanov <dfirblog(a)gmail.com> Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com> Cc: stable(a)vger.kernel.org diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c index cf659c8feb29..a95c1b9cc5b5 100644 --- a/drivers/md/dm-verity-target.c +++ b/drivers/md/dm-verity-target.c @@ -272,8 +272,10 @@ static int verity_handle_err(struct dm_verity *v, enum verity_block_type type, if (v->mode == DM_VERITY_MODE_LOGGING) return 0; - if (v->mode == DM_VERITY_MODE_RESTART) - kernel_restart("dm-verity device corrupted"); + if (v->mode == DM_VERITY_MODE_RESTART) { + pr_emerg("dm-verity device corrupted\n"); + emergency_restart(); + } if (v->mode == DM_VERITY_MODE_PANIC) panic("dm-verity device corrupted"); @@ -596,6 +598,23 @@ static void verity_finish_io(struct dm_verity_io *io, blk_status_t status) if (!static_branch_unlikely(&use_bh_wq_enabled) || !io->in_bh) verity_fec_finish_io(io); + if (unlikely(status != BLK_STS_OK) && + unlikely(!(bio->bi_opf & REQ_RAHEAD)) && + !verity_is_system_shutting_down()) { + if (v->mode == DM_VERITY_MODE_RESTART || + v->mode == DM_VERITY_MODE_PANIC) + DMERR_LIMIT("%s has error: %s", v->data_dev->name, + blk_status_to_str(status)); + + if (v->mode == DM_VERITY_MODE_RESTART) { + pr_emerg("dm-verity device corrupted\n"); + emergency_restart(); + } + + if (v->mode == DM_VERITY_MODE_PANIC) + panic("dm-verity device corrupted"); + } + bio_endio(bio); }

1 month

3
3
0 0

Re: [PATCH 6.11 000/695] 6.11.2-rc1 review

by Ronald Warsow

Hi Greg no regressions here on x86_64 (RKL, Intel 11th Gen. CPU) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

1 month

1
0
0 0

[REGRESSION]: cephfs: file corruption when reading content via in-kernel ceph client

by Christian Ebner

Hi, some of our customers (Proxmox VE) are seeing issues with file corruptions when accessing contents located on CephFS via the in-kernel Ceph client [0,1], we managed to reproduce this regression on kernels up to the latest 6.11-rc6. Accessing the same content on the CephFS using the FUSE client or the in-kernel ceph client with older kernels (Ubuntu kernel on v6.5) does not show file corruptions. Unfortunately the corruption is hard to reproduce, seemingly only a small subset of files is affected. However, once a file is affected, the issue is persistent and can easily be reproduced. Bisection with the reproducer points to this commit: "92b6cc5d: netfs: Add iov_iters to (sub)requests to describe various buffers" Description of the issue: A file was copied from local filesystem to cephfs via: ``` cp /tmp/proxmox-backup-server_3.2-1.iso /mnt/pve/cephfs/proxmox-backup-server_3.2-1.iso ``` * sha256sum on local filesystem:`1d19698e8f7e769cf0a0dcc7ba0018ef5416c5ec495d5e61313f9c84a4237607 /tmp/proxmox-backup-server_3.2-1.iso` * sha256sum on cephfs with kernel up to above commit: `1d19698e8f7e769cf0a0dcc7ba0018ef5416c5ec495d5e61313f9c84a4237607 /mnt/pve/cephfs/proxmox-backup-server_3.2-1.iso` * sha256sum on cephfs with kernel after above commit: `89ad3620bf7b1e0913b534516cfbe48580efbaec944b79951e2c14e5e551f736 /mnt/pve/cephfs/proxmox-backup-server_3.2-1.iso` * removing and/or recopying the file does not change the issue, the corrupt checksum remains the same. * accessing the same file from different clients results in the same output: the one with above patch applied do show the incorrect checksum, ones without the patch show the correct checksum. * the issue persists even across reboot of the ceph cluster and/or clients. * the file is indeed corrupt after reading, as verified by a `cmp -b`. Interestingly, the first 4M contain the correct data, the following 4M are read as all zeros, which differs from the original data. * the issue is related to the readahead size: mounting the cephfs with a `rasize=0` makes the issue disappear, same is true for sizes up to 128k (please note that the ranges as initially reported on the mailing list [3] are not correct for rasize [0..128k] the file is not corrupted). In the bugtracker issue [4] I attached a ftrace with "*ceph*" as filter while performing a read on the latest kernel 6.11-rc6 while performing ``` dd if=/mnt/pve/cephfs/proxmox-backup-server_3.2-1.iso of=/tmp/test.out bs=8M count=1 ``` the relevant part shown by task `dd-26192`. Please let me know if I can provide further information or debug outputs in order to narrow down the issue. [0] https://forum.proxmox.com/threads/78340/post-676129 [1] https://forum.proxmox.com/threads/149249/ [2] https://forum.proxmox.com/threads/151291/ [3] https://lore.kernel.org/lkml/db686d0c-2f27-47c8-8c14-26969433b13b@proxmox.c… [4] https://bugzilla.kernel.org/show_bug.cgi?id=219237 #regzbot introduced: 92b6cc5d Regards, Christian Ebner

1 month

4
9
0 0

[PATCH] irqchip/sifive-plic: Unmask interrupt in plic_irq_enable()

by Nam Cao

It is possible that an interrupt is disabled and masked at the same time. When the interrupt is enabled again by enable_irq(), only plic_irq_enable() is called, not plic_irq_unmask(). The interrupt remains masked and never raises. An example where interrupt is both disabled and masked is when handle_fasteoi_irq() is the handler, and IRQS_ONESHOT is set. The interrupt handler: 1. Mask the interrupt 2. Handle the interrupt 3. Check if interrupt is still enabled, and unmask it (see cond_unmask_eoi_irq()) If another task disables the interrupt in the middle of the above steps, the interrupt will not get unmasked, and will remain masked when it is enabled in the future. The problem is occasionally observed when PREEMPT_RT is enabled, because PREEMPT_RT add the IRQS_ONESHOT flag. But PREEMPT_RT only makes the problem more likely to appear, the bug has been around since commit a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask operations"). Fix it by unmasking interrupt in plic_irq_enable(). Fixes: a1706a1c5062 ("irqchip/sifive-plic: Separate the enable and mask operations"). Signed-off-by: Nam Cao <namcao(a)linutronix.de> Cc: stable(a)vger.kernel.org --- drivers/irqchip/irq-sifive-plic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c index 2f6ef5c495bd..0efbf14ec9fa 100644 --- a/drivers/irqchip/irq-sifive-plic.c +++ b/drivers/irqchip/irq-sifive-plic.c @@ -128,6 +128,9 @@ static inline void plic_irq_toggle(const struct cpumask *mask, static void plic_irq_enable(struct irq_data *d) { + struct plic_priv *priv = irq_data_get_irq_chip_data(d); + + writel(1, priv->regs + PRIORITY_BASE + d->hwirq * PRIORITY_PER_ID); plic_irq_toggle(irq_data_get_effective_affinity_mask(d), d, 1); } -- 2.39.5

1 month

2
1
0 0

[PATCH v3 0/4] ov08x40: Enable use of ov08x40 on Qualcomm X1E80100 CRD

by Bryan O'Donoghue

Changes in v3: - Drops assigned-clock-* from description retains in example - Sakari, Krzysztof - Updates example fake clock names to ov08x40_* instead of copy/paste ov9282_clk -> ov08x40_clk, ov9282_clk_parent -> ov08x40_clk_parent - bod - Link to v2: https://lore.kernel.org/r/20241001-b4-master-24-11-25-ov08x40-v2-0-e478976b… Changes in v2: - Drops "-" in ovti,ov08x40.yaml after description: - Rob - Adds ":" after first line of description text - Rob - dts -> DT in commit log - Rob - Removes dependency on 'xvclk' as a name in yaml and driver - Sakari - Uses assigned-clock, assigned-clock-parents and assigned-clock-rates - Sakari - Drops clock-frequency - Sakarai, Krzysztof - Drops dovdd-supply, avdd-supply, dvdd-supply and reset-gpios as required, its perfectly possible not to have the reset GPIO or the power rails under control of the SoC. - bod - Link to v1: https://lore.kernel.org/r/20240926-b4-master-24-11-25-ov08x40-v1-0-e4d5fbd3… V1: This series brings fixes and updates to ov08x40 which allows for use of this sensor on the Qualcomm x1e80100 CRD but also on any other dts based system. Firstly there's a fix for the pseudo burst mode code that was added in 8f667d202384 ("media: ov08x40: Reduce start streaming time"). Not every I2C controller can handle an arbitrary sized write, this is the case on Qualcomm CAMSS/CCI I2C sensor interfaces which limit the transaction size and communicate this limit via I2C quirks. A simple fix to optionally break up the large submitted burst into chunks not exceeding adapter->quirk size fixes. Secondly then is addition of a yaml description for the ov08x40 and extension of the driver to support OF probe and powering on of the power rails from the driver instead of from ACPI. Once done the sensor works without further modification on the Qualcomm x1e80100 CRD. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue(a)linaro.org> --- Bryan O'Donoghue (4): media: ov08x40: Fix burst write sequence media: dt-bindings: Add OmniVision OV08X40 media: ov08x40: Rename ext_clk to xvclk media: ov08x40: Add OF probe support .../bindings/media/i2c/ovti,ov08x40.yaml | 116 +++++++++++++ drivers/media/i2c/ov08x40.c | 179 ++++++++++++++++++--- 2 files changed, 272 insertions(+), 23 deletions(-) --- base-commit: 2b7275670032a98cba266bd1b8905f755b3e650f change-id: 20240926-b4-master-24-11-25-ov08x40-c6f477aaa6a4 Best regards, -- Bryan O'Donoghue <bryan.odonoghue(a)linaro.org>

1 month

1
1
0 0

Please include [PATCH net] netkit: Assign missing bpf_net_context

by Maksym Kutsevol

Hi, Subject: [PATCH net] netkit: Assign missing bpf_net_context commit id: 157f29152b61ca41809dd7ead29f5733adeced19 kernel versions: 6.11 The patch was sent before 6.11 was cut final, but it didn't make it. We are seeing kernel crashes on 6.11.1 without this commit, with the exact signature that the patch fixes. Thank you. Regards, Maksym

1 month

1
0
0 0

Re: [PATCH] arm64: dts: marvell: cn9130-sr-som: fix cp0 mdio0 mdio pin numbers

by kernel test robot

Hi, Thanks for your patch. FYI: kernel test robot notices the stable kernel rule is not satisfied. The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#opt… Rule: add the tag "Cc: stable(a)vger.kernel.org" in the sign-off area to have the patch automatically included in the stable tree. Subject: [PATCH] arm64: dts: marvell: cn9130-sr-som: fix cp0 mdio0 mdio pin numbers Link: https://lore.kernel.org/stable/20241002-cn9130-som-mdio-v1-1-0942be4dc550%4… -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 month

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024