- Linux-stable-mirror - lists.linaro.org

[PATCH AUTOSEL 6.14 01/20] ASoC: imx-card: Adjust over allocation of memory in imx_card_parse_of()

by Sasha Levin

From: Chenyuan Yang <chenyuan0y(a)gmail.com> [ Upstream commit a9a69c3b38c89d7992fb53db4abb19104b531d32 ] Incorrect types are used as sizeof() arguments in devm_kcalloc(). It should be sizeof(dai_link_data) for link_data instead of sizeof(snd_soc_dai_link). This is found by our static analysis tool. Signed-off-by: Chenyuan Yang <chenyuan0y(a)gmail.com> Link: https://patch.msgid.link/20250406210854.149316-1-chenyuan0y@gmail.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/fsl/imx-card.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/imx-card.c b/sound/soc/fsl/imx-card.c index 21f617f6f9fa8..566214cb3d60c 100644 --- a/sound/soc/fsl/imx-card.c +++ b/sound/soc/fsl/imx-card.c @@ -543,7 +543,7 @@ static int imx_card_parse_of(struct imx_card_data *data) if (!card->dai_link) return -ENOMEM; - data->link_data = devm_kcalloc(dev, num_links, sizeof(*link), GFP_KERNEL); + data->link_data = devm_kcalloc(dev, num_links, sizeof(*link_data), GFP_KERNEL); if (!data->link_data) return -ENOMEM; -- 2.39.5

4 months, 1 week

1
19
0 0

[PATCH] vfio/pci: Align huge faults to order

by Alex Williamson

The vfio-pci huge_fault handler doesn't make any attempt to insert a mapping containing the faulting address, it only inserts mappings if the faulting address and resulting pfn are aligned. This works in a lot of cases, particularly in conjunction with QEMU where DMA mappings linearly fault the mmap. However, there are configurations where we don't get that linear faulting and pages are faulted on-demand. The scenario reported in the bug below is such a case, where the physical address width of the CPU is greater than that of the IOMMU, resulting in a VM where guest firmware has mapped device MMIO beyond the address width of the IOMMU. In this configuration, the MMIO is faulted on demand and tracing indicates that occasionally the faults generate a VM_FAULT_OOM. Given the use case, this results in a "error: kvm run failed Bad address", killing the VM. The host is not under memory pressure in this test, therefore it's suspected that VM_FAULT_OOM is actually the result of a NULL return from __pte_offset_map_lock() in the get_locked_pte() path from insert_pfn(). This suggests a potential race inserting a pte concurrent to a pmd, and maybe indicates some deficiency in the mm layer properly handling such a case. Nevertheless, Peter noted the inconsistency of vfio-pci's huge_fault handler where our mapping granularity depends on the alignment of the faulting address relative to the order rather than aligning the faulting address to the order to more consistently insert huge mappings. This change not only uses the page tables more consistently and efficiently, but as any fault to an aligned page results in the same mapping, the race condition suspected in the VM_FAULT_OOM is avoided. Reported-by: Adolfo <adolfotregosa(a)gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=220057 Fixes: 09dfc8a5f2ce ("vfio/pci: Fallback huge faults for unaligned pfn") Cc: stable(a)vger.kernel.org Tested-by: Adolfo <adolfotregosa(a)gmail.com> Co-developed-by: Peter Xu <peterx(a)redhat.com> Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> --- drivers/vfio/pci/vfio_pci_core.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c index 35f9046af315..6328c3a05bcd 100644 --- a/drivers/vfio/pci/vfio_pci_core.c +++ b/drivers/vfio/pci/vfio_pci_core.c @@ -1646,14 +1646,14 @@ static vm_fault_t vfio_pci_mmap_huge_fault(struct vm_fault *vmf, { struct vm_area_struct *vma = vmf->vma; struct vfio_pci_core_device *vdev = vma->vm_private_data; - unsigned long pfn, pgoff = vmf->pgoff - vma->vm_pgoff; + unsigned long addr = vmf->address & ~((PAGE_SIZE << order) - 1); + unsigned long pgoff = (addr - vma->vm_start) >> PAGE_SHIFT; + unsigned long pfn = vma_to_pfn(vma) + pgoff; vm_fault_t ret = VM_FAULT_SIGBUS; - pfn = vma_to_pfn(vma) + pgoff; - - if (order && (pfn & ((1 << order) - 1) || - vmf->address & ((PAGE_SIZE << order) - 1) || - vmf->address + (PAGE_SIZE << order) > vma->vm_end)) { + if (order && (addr < vma->vm_start || + addr + (PAGE_SIZE << order) > vma->vm_end || + pfn & ((1 << order) - 1))) { ret = VM_FAULT_FALLBACK; goto out; } -- 2.48.1

4 months, 1 week

2
2
0 0

Re: sound/pci/hda: add quirk for HP Spectre x360 15-eb0xxx

by Takashi Iwai

On Tue, 06 May 2025 12:11:26 +0200, Ezra Khuzadi wrote: > > > Hi Takashi, Jaroslav, all maintainers, > > Could you please review it or let me know if any changes are needed? This is > my first kernel patch as a student, and I’d appreciate any feedback. I guess you submitted to a wrong address. The proper mailing list is linux-sound(a)vger.kernel.org. Please try to resubmit. And, make sure that your mailer doesn't break tabs and whitespaces. You can test sending to yourself and verify that the submitted patch is properly applicable beforehand. thanks, Takashi > > Thanks, > Ezra Khuzadi > > On Wed, Apr 30, 2025 at 1:43 AM Ezra Khuzadi <ekhuzadi(a)uci.edu> wrote: > > sound/pci/hda/patch_realtek.c: add quirk for HP Spectre x360 15-eb0xxx > > Add subsystem ID 0x86e5 for HP Spectre x360 15-eb0xxx so that > ALC285_FIXUP_HP_SPECTRE_X360_EB1 (GPIO amp-enable, mic-mute LED and > pinconfigs) is applied. > > Tested on HP Spectre x360 15-eb0043dx (Vendor 0x10ec0285, Subsys > 0x103c86e5) > with legacy HDA driver and hda-verb toggles: > > $ cat /proc/asound/card0/codec#0 \ > | sed -n -e '1,5p;/Vendor Id:/p;/Subsystem Id:/p' > Codec: Realtek ALC285 > Vendor Id: 0x10ec0285 > Subsystem Id: 0x103c86e5 > > $ dmesg | grep -i realtek > [ 5.828728] snd_hda_codec_realtek ehdaudio0D0: ALC285: picked fixup > for PCI SSID 103c:86e5 > > Signed-off-by: Ezra Khuzadi <ekhuzadi(a)uci.edu> > Cc: stable(a)vger.kernel.org > > --- > sound/pci/hda/patch_realtek.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > index 877137cb09ac..82ad105e7fa9 100644 > --- a/sound/pci/hda/patch_realtek.c > +++ b/sound/pci/hda/patch_realtek.c > @@ -10563,6 +10563,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = > { > SND_PCI_QUIRK(0x103c, 0x86c7, "HP Envy AiO 32", > ALC274_FIXUP_HP_ENVY_GPIO), > + SND_PCI_QUIRK(0x103c, 0x86e5, "HP Spectre x360 15-eb0xxx", > ALC285_FIXUP_HP_SPECTRE_X360_EB1), > SND_PCI_QUIRK(0x103c, 0x86e7, "HP Spectre x360 15-eb0xxx", > ALC285_FIXUP_HP_SPECTRE_X360_EB1), > SND_PCI_QUIRK(0x103c, 0x86e8, "HP Spectre x360 15-eb0xxx", > ALC285_FIXUP_HP_SPECTRE_X360_EB1), > SND_PCI_QUIRK(0x103c, 0x86f9, "HP Spectre x360 13-aw0xxx", > ALC285_FIXUP_HP_SPECTRE_X360_MUTE_LED), > > On Wed, Apr 30, 2025 at 1:33 AM kernel test robot <lkp(a)intel.com> wrote: > > > > Hi, > > > > Thanks for your patch. > > > > FYI: kernel test robot notices the stable kernel rule is not satisfied. > > > > The check is based on > https://urldefense.com/v3/__https://www.kernel.org/doc/html/latest/process/… > > > > 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: sound/pci/hda: add quirk for HP Spectre x360 15-eb0xxx > > Link: > https://urldefense.com/v3/__https://lore.kernel.org/stable/CAPXr0uxh0c_2b2-… > > > > -- > > 0-DAY CI Kernel Test Service > > > https://urldefense.com/v3/__https://github.com/intel/lkp-tests/wiki__;!!CzA… > > > > > > >

4 months, 1 week

1
0
0 0

[PATCH net 5/6] can: mcan: m_can_class_unregister(): fix order of unregistration calls

by Marc Kleine-Budde

If a driver is removed, the driver framework invokes the driver's remove callback. A CAN driver's remove function calls unregister_candev(), which calls net_device_ops::ndo_stop further down in the call stack for interfaces which are in the "up" state. The removal of the module causes a warning, as can_rx_offload_del() deletes the NAPI, while it is still active, because the interface is still up. To fix the warning, first unregister the network interface, which calls net_device_ops::ndo_stop, which disables the NAPI, and then call can_rx_offload_del(). Fixes: 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20250502-can-rx-offload-del-v1-3-59a9b131589d@peng… Reviewed-by: Markus Schneider-Pargmann <msp(a)baylibre.com> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/m_can/m_can.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c index 326ede9d400f..c2c116ce1087 100644 --- a/drivers/net/can/m_can/m_can.c +++ b/drivers/net/can/m_can/m_can.c @@ -2463,9 +2463,9 @@ EXPORT_SYMBOL_GPL(m_can_class_register); void m_can_class_unregister(struct m_can_classdev *cdev) { + unregister_candev(cdev->net); if (cdev->is_peripheral) can_rx_offload_del(&cdev->offload); - unregister_candev(cdev->net); } EXPORT_SYMBOL_GPL(m_can_class_unregister); -- 2.47.2

4 months, 1 week

2
1
0 0

[PATCH net 4/6] can: rockchip_canfd: rkcanfd_remove(): fix order of unregistration calls

by Marc Kleine-Budde

If a driver is removed, the driver framework invokes the driver's remove callback. A CAN driver's remove function calls unregister_candev(), which calls net_device_ops::ndo_stop further down in the call stack for interfaces which are in the "up" state. The removal of the module causes a warning, as can_rx_offload_del() deletes the NAPI, while it is still active, because the interface is still up. To fix the warning, first unregister the network interface, which calls net_device_ops::ndo_stop, which disables the NAPI, and then call can_rx_offload_del(). Fixes: ff60bfbaf67f ("can: rockchip_canfd: add driver for Rockchip CAN-FD controller") Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20250502-can-rx-offload-del-v1-2-59a9b131589d@peng… Reviewed-by: Markus Schneider-Pargmann <msp(a)baylibre.com> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/rockchip/rockchip_canfd-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c index 7107a37da36c..c3fb3176ce42 100644 --- a/drivers/net/can/rockchip/rockchip_canfd-core.c +++ b/drivers/net/can/rockchip/rockchip_canfd-core.c @@ -937,8 +937,8 @@ static void rkcanfd_remove(struct platform_device *pdev) struct rkcanfd_priv *priv = platform_get_drvdata(pdev); struct net_device *ndev = priv->ndev; - can_rx_offload_del(&priv->offload); rkcanfd_unregister(priv); + can_rx_offload_del(&priv->offload); free_candev(ndev); } -- 2.47.2

4 months, 1 week

2
1
0 0

[PATCH net 3/6] can: mcp251xfd: mcp251xfd_remove(): fix order of unregistration calls

by Marc Kleine-Budde

If a driver is removed, the driver framework invokes the driver's remove callback. A CAN driver's remove function calls unregister_candev(), which calls net_device_ops::ndo_stop further down in the call stack for interfaces which are in the "up" state. With the mcp251xfd driver the removal of the module causes the following warning: | WARNING: CPU: 0 PID: 352 at net/core/dev.c:7342 __netif_napi_del_locked+0xc8/0xd8 as can_rx_offload_del() deletes the NAPI, while it is still active, because the interface is still up. To fix the warning, first unregister the network interface, which calls net_device_ops::ndo_stop, which disables the NAPI, and then call can_rx_offload_del(). Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20250502-can-rx-offload-del-v1-1-59a9b131589d@peng… Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c index 064d81c724f4..c30b04f8fc0d 100644 --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c @@ -2198,8 +2198,8 @@ static void mcp251xfd_remove(struct spi_device *spi) struct mcp251xfd_priv *priv = spi_get_drvdata(spi); struct net_device *ndev = priv->ndev; - can_rx_offload_del(&priv->offload); mcp251xfd_unregister(priv); + can_rx_offload_del(&priv->offload); spi->max_speed_hz = priv->spi_max_speed_hz_orig; free_candev(ndev); } -- 2.47.2

4 months, 1 week

2
1
0 0

[regression 6.1.y] discard/TRIM through RAID10 blocking (was: Re: Bug#1104460: linux-image-6.1.0-34-powerpc64le: Discard broken) with RAID10: BUG: kernel tried to execute user page (0) - exploit attempt?

by Salvatore Bonaccorso

Hi We got a regression report in Debian after the update from 6.1.133 to 6.1.135. Melvin is reporting that discard/trimm trhough a RAID10 array stalls idefintively. The full report is inlined below and originates from https://bugs.debian.org/1104460 . On Wed, Apr 30, 2025 at 04:46:50PM +0200, Melvin Vermeeren wrote: > Package: src:linux > Version: 6.1.135-1 > Severity: important > Tags: upstream > X-Debbugs-Cc: vermeeren(a)vermwa.re > > Dear Maintainer, > > Upgrading from linux-image-6.1.0-33-powerpc64le (6.1.133-1) to > linux-image-6.1.0-34-powerpc64le (6.1.135-1) it appears there is a > serious regression bug related to discard/TRIM through a RAID10 array. > This only affects RAID10, RAID1 array on the same SSD device is not > affected. Array in question is a fairly standard RAID10 in 2far layout. > > md127 : active raid10 dm-1[2] dm-0[0] > 1872188416 blocks super 1.2 512K chunks 2 far-copies [2/2] [UU] > bitmap: 1/1 pages [64KB], 65536KB chunk > > Any discard operation will result in quite a long kernel error. The > calling process will either segfault (swapon) or, more likely, be stuck > forever (Qemu, fstrim) in the D state per htop. The iostat utility > reports a %util of 100% for any device on top of (directly or > indirectly) of the RAID10 device, despite there being no read or write > requests to the devices or any other acitivty. > > Stuck processes cannot be terminated or killed. Attempting to reboot > normally will result in a stuck machine on shutdown, so only a > REISUB-style reboot will work via procfs sysrq. > > I have briefly diffed and inspected commits between the two kernel > versions and I suspect the commit below may be at fault. Do keep in mind > I have not verified this in any way, so I may be wrong. > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… > > Considering this is shipped as part of a stable security update I > consider it quite a serious bug. Affected hosts will not boot up > cleanly, may not have swap, processes will freeze upon discard and clean > reboot it also not possible. > > More logs available upon request. > > Many thanks, > > Melvin Vermeeren. > > -- Package-specific info: > ** Version: > Linux version 6.1.0-34-powerpc64le (debian-kernel(a)lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP Debian 6.1.135-1 (2025-04-25) > > ** Command line: > root=/dev/mapper/...-root ro quiet > > ** Not tainted > > ** Kernel log: > # /etc/fstab entry > /dev/.../swap none swap sw,discard=once 0 0 > > ~# swapon -va > swapon: /dev/mapper/...-swap: found signature [pagesize=65536, signature=swap] > swapon: /dev/mapper/...-swap: pagesize=65536, swapsize=17179869184, devsize=17179869184 > swapon /dev/mapper/...-swap > Segmentation fault > > ~# dmesg > ... > [ 223.017257] kernel tried to execute user page (0) - exploit attempt? (uid: 0) > [ 223.017287] BUG: Unable to handle kernel instruction fetch (NULL pointer?) > [ 223.017301] Faulting instruction address: 0x00000000 > [ 223.017326] Oops: Kernel access of bad area, sig: 11 [#1] > [ 223.017338] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV > [ 223.017365] Modules linked in: bridge stp llc binfmt_misc nft_connlimit nf_conncount ast drm_vram_helper drm_ttm_helper ofpart ipmi_powernv ttm ipmi_devintf powernv_flash at24 mtd ipmi_msghandler opal_prd regmap_i2c drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops i2c_algo_bit sg nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nf_tables nfnetlink drm loop fuse drm_panel_orientation_quirks configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 dm_crypt dm_integrity dm_bufio dm_mod macvlan raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc_t10dif crct10dif_generic crc64 crct10dif_common xhci_pci xts ecb xhci_hcd ctr vmx_crypto gf128mul crc32c_vpmsum tg3 mpt3sas usbcore raid_class libphy scsi_transport_sas usb_common > [ 223.017812] CPU: 8 PID: 10609 Comm: swapon Not tainted 6.1.0-34-powerpc64le #1 Debian 6.1.135-1 > [ 223.017844] Hardware name: T2P9D01 REV 1.01 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV > [ 223.017879] NIP: 0000000000000000 LR: c0000000003efe70 CTR: 0000000000000000 > [ 223.017926] REGS: c0000000276cf200 TRAP: 0400 Not tainted (6.1.0-34-powerpc64le Debian 6.1.135-1) > [ 223.017979] MSR: 900000004280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24004480 XER: 00000004 > [ 223.018060] CFAR: c0000000003efe6c IRQMASK: 0 > GPR00: c0000000003efec4 c0000000276cf4a0 c000000001148100 0000000000092800 > GPR04: 0000000000000000 0000000000000003 0000000000000c00 c00000000296e700 > GPR08: c00000000c0e9700 00000c0000090800 0000000000000000 0000000000002000 > GPR12: 0000000000000000 c000001ffffd9800 c0000000446b8c00 0000000000000000 > GPR16: 0000000000000400 0000000000000000 0000000000000001 000000000000c812 > GPR20: 000000000000c911 c0000000170c5700 c00000000296e718 c00000000296e3f0 > GPR24: 0000000000000000 00000000000003ff 0000000000000000 0000000000000c00 > GPR28: c000200009e2dd00 c00000000296e718 00000c0000092800 0000000000092c00 > [ 223.018372] NIP [0000000000000000] 0x0 > [ 223.018397] LR [c0000000003efe70] mempool_alloc+0xa0/0x210 > [ 223.018435] Call Trace: > [ 223.018453] [c0000000276cf4a0] [c0000000003efec4] mempool_alloc+0xf4/0x210 (unreliable) > [ 223.018507] [c0000000276cf520] [c000000000743bf8] bio_alloc_bioset+0x368/0x510 > [ 223.018552] [c0000000276cf5a0] [c000000000743e74] bio_alloc_clone+0x44/0xa0 > [ 223.018601] [c0000000276cf5e0] [c008000015793adc] md_account_bio+0x54/0xb0 [md_mod] > [ 223.018655] [c0000000276cf610] [c00800001567778c] raid10_make_request+0xc54/0x1040 [raid10] > [ 223.018687] [c0000000276cf770] [c00800001579a290] md_handle_request+0x198/0x380 [md_mod] > [ 223.018735] [c0000000276cf800] [c00000000074c32c] __submit_bio+0x9c/0x250 > [ 223.018773] [c0000000276cf840] [c00000000074ca88] submit_bio_noacct_nocheck+0x178/0x3f0 > [ 223.018825] [c0000000276cf8b0] [c000000000743e08] blk_next_bio+0x68/0x90 > [ 223.018863] [c0000000276cf8e0] [c000000000758c60] __blkdev_issue_discard+0x180/0x280 > [ 223.018898] [c0000000276cf980] [c000000000758de8] blkdev_issue_discard+0x88/0x120 > [ 223.018927] [c0000000276cfa00] [c0000000004a9e8c] sys_swapon+0x11dc/0x18a0 > [ 223.018971] [c0000000276cfb50] [c00000000002b038] system_call_exception+0x138/0x260 > [ 223.019015] [c0000000276cfe10] [c00000000000c0f0] system_call_vectored_common+0xf0/0x280 > [ 223.019058] --- interrupt: 3000 at 0x7fff95146770 > [ 223.019095] NIP: 00007fff95146770 LR: 00007fff95146770 CTR: 0000000000000000 > [ 223.019132] REGS: c0000000276cfe80 TRAP: 3000 Not tainted (6.1.0-34-powerpc64le Debian 6.1.135-1) > [ 223.019182] MSR: 900000000280f033 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 48002481 XER: 00000000 > [ 223.019267] IRQMASK: 0 > GPR00: 0000000000000057 00007fffdca2ace0 00007fff95256f00 00000001220a1c20 > GPR04: 0000000000030000 000000000000001e 000000000000000a 000000000000000a > GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > GPR12: 0000000000000000 00007fff955dcbc0 0000000000000000 0000000000000000 > GPR16: 0000000000000000 00000001104066b0 00007fffdca2afc8 000000011040cbd0 > GPR20: 000000011040cbd8 0000000000000000 0000000000010000 00007fffdca2aff0 > GPR24: 00007fffdca2afd0 0000000000000003 0000000000030000 0000000400000000 > GPR28: 00000001220a1c20 000000000000fff6 00000001220a30a0 0000000000100000 > [ 223.019542] NIP [00007fff95146770] 0x7fff95146770 > [ 223.019568] LR [00007fff95146770] 0x7fff95146770 > [ 223.019595] --- interrupt: 3000 > [ 223.019604] Instruction dump: > [ 223.019626] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX > [ 223.019665] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX > [ 223.019712] ---[ end trace 0000000000000000 ]--- > > [ 224.623456] note: swapon[10609] exited with irqs disabled > [ 224.623483] ------------[ cut here ]------------ > [ 224.623502] WARNING: CPU: 8 PID: 10609 at kernel/exit.c:816 do_exit+0x94/0xbc0 > [ 224.623516] Modules linked in: bridge stp llc binfmt_misc nft_connlimit nf_conncount ast drm_vram_helper drm_ttm_helper ofpart ipmi_powernv ttm ipmi_devintf powernv_flash at24 mtd ipmi_msghandler opal_prd regmap_i2c drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops i2c_algo_bit sg nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nf_tables nfnetlink drm loop fuse drm_panel_orientation_quirks configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 dm_crypt dm_integrity dm_bufio dm_mod macvlan raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc_t10dif crct10dif_generic crc64 crct10dif_common xhci_pci xts ecb xhci_hcd ctr vmx_crypto gf128mul crc32c_vpmsum tg3 mpt3sas usbcore raid_class libphy scsi_transport_sas usb_common > [ 224.623825] CPU: 8 PID: 10609 Comm: swapon Tainted: G D 6.1.0-34-powerpc64le #1 Debian 6.1.135-1 > [ 224.623860] Hardware name: T2P9D01 REV 1.01 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV > [ 224.623892] NIP: c000000000140fa4 LR: c000000000140fa0 CTR: 0000000000000000 > [ 224.623935] REGS: c0000000276cecb0 TRAP: 0700 Tainted: G D (6.1.0-34-powerpc64le Debian 6.1.135-1) > [ 224.623969] MSR: 9000000002029033 <SF,HV,VEC,EE,ME,IR,DR,RI,LE> CR: 24004222 XER: 00000004 > [ 224.624012] CFAR: c00000000013ea68 IRQMASK: 0 > GPR00: c000000000140fa0 c0000000276cef50 c000000001148100 0000000000000000 > GPR04: 0000000000000000 c0000000276cee20 c0000000276cee18 0000001ffb000000 > GPR08: 0000000000000027 c0000000276cf9b0 0000000000000000 0000000000004000 > GPR12: 0000000031c40000 c000001ffffd9800 c0000000446b8c00 0000000000000000 > GPR16: 0000000000000400 0000000000000000 0000000000000001 000000000000c812 > GPR20: 000000000000c911 c0000000170c5700 c00000000296e718 c00000000296e3f0 > GPR24: 0000000000000000 00000000000003ff 0000000000000000 0000000000000c00 > GPR28: 000000000000000b c00000001ce25d80 c000000078409c00 c000000026529d80 > [ 224.624208] NIP [c000000000140fa4] do_exit+0x94/0xbc0 > [ 224.624239] LR [c000000000140fa0] do_exit+0x90/0xbc0 > [ 224.624269] Call Trace: > [ 224.624274] [c0000000276cef50] [c000000000140fa0] do_exit+0x90/0xbc0 (unreliable) > [ 224.624308] [c0000000276cf020] [c000000000141b80] make_task_dead+0xb0/0x1f0 > [ 224.624320] [c0000000276cf0a0] [c000000000025718] oops_end+0x188/0x1c0 > [ 224.624341] [c0000000276cf120] [c00000000007f72c] __bad_page_fault+0x18c/0x1b0 > [ 224.624375] [c0000000276cf190] [c000000000008cd4] instruction_access_common_virt+0x194/0x1a0 > [ 224.624421] --- interrupt: 400 at 0x0 > [ 224.624438] NIP: 0000000000000000 LR: c0000000003efe70 CTR: 0000000000000000 > [ 224.624471] REGS: c0000000276cf200 TRAP: 0400 Tainted: G D (6.1.0-34-powerpc64le Debian 6.1.135-1) > [ 224.624507] MSR: 900000004280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24004480 XER: 00000004 > [ 224.624544] CFAR: c0000000003efe6c IRQMASK: 0 > GPR00: c0000000003efec4 c0000000276cf4a0 c000000001148100 0000000000092800 > GPR04: 0000000000000000 0000000000000003 0000000000000c00 c00000000296e700 > GPR08: c00000000c0e9700 00000c0000090800 0000000000000000 0000000000002000 > GPR12: 0000000000000000 c000001ffffd9800 c0000000446b8c00 0000000000000000 > GPR16: 0000000000000400 0000000000000000 0000000000000001 000000000000c812 > GPR20: 000000000000c911 c0000000170c5700 c00000000296e718 c00000000296e3f0 > GPR24: 0000000000000000 00000000000003ff 0000000000000000 0000000000000c00 > GPR28: c000200009e2dd00 c00000000296e718 00000c0000092800 0000000000092c00 > [ 224.624732] NIP [0000000000000000] 0x0 > [ 224.624749] LR [c0000000003efe70] mempool_alloc+0xa0/0x210 > [ 224.624771] --- interrupt: 400 > [ 224.624789] [c0000000276cf4a0] [c0000000003efec4] mempool_alloc+0xf4/0x210 (unreliable) > [ 224.624823] [c0000000276cf520] [c000000000743bf8] bio_alloc_bioset+0x368/0x510 > [ 224.624859] [c0000000276cf5a0] [c000000000743e74] bio_alloc_clone+0x44/0xa0 > [ 224.624892] [c0000000276cf5e0] [c008000015793adc] md_account_bio+0x54/0xb0 [md_mod] > [ 224.624930] [c0000000276cf610] [c00800001567778c] raid10_make_request+0xc54/0x1040 [raid10] > [ 224.624964] [c0000000276cf770] [c00800001579a290] md_handle_request+0x198/0x380 [md_mod] > [ 224.624997] [c0000000276cf800] [c00000000074c32c] __submit_bio+0x9c/0x250 > [ 224.625018] [c0000000276cf840] [c00000000074ca88] submit_bio_noacct_nocheck+0x178/0x3f0 > [ 224.625043] [c0000000276cf8b0] [c000000000743e08] blk_next_bio+0x68/0x90 > [ 224.625066] [c0000000276cf8e0] [c000000000758c60] __blkdev_issue_discard+0x180/0x280 > [ 224.625091] [c0000000276cf980] [c000000000758de8] blkdev_issue_discard+0x88/0x120 > [ 224.625115] [c0000000276cfa00] [c0000000004a9e8c] sys_swapon+0x11dc/0x18a0 > [ 224.625139] [c0000000276cfb50] [c00000000002b038] system_call_exception+0x138/0x260 > [ 224.625164] [c0000000276cfe10] [c00000000000c0f0] system_call_vectored_common+0xf0/0x280 > [ 224.625201] --- interrupt: 3000 at 0x7fff95146770 > [ 224.625270] NIP: 00007fff95146770 LR: 00007fff95146770 CTR: 0000000000000000 > [ 224.625367] REGS: c0000000276cfe80 TRAP: 3000 Tainted: G D (6.1.0-34-powerpc64le Debian 6.1.135-1) > [ 224.625458] MSR: 900000000000f033 <SF,HV,EE,PR,FP,ME,IR,DR,RI,LE> CR: 48002481 XER: 00000000 > [ 224.625570] IRQMASK: 0 > GPR00: 0000000000000057 00007fffdca2ace0 00007fff95256f00 00000001220a1c20 > GPR04: 0000000000030000 000000000000001e 000000000000000a 000000000000000a > GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > GPR12: 0000000000000000 00007fff955dcbc0 0000000000000000 0000000000000000 > GPR16: 0000000000000000 00000001104066b0 00007fffdca2afc8 000000011040cbd0 > GPR20: 000000011040cbd8 0000000000000000 0000000000010000 00007fffdca2aff0 > GPR24: 00007fffdca2afd0 0000000000000003 0000000000030000 0000000400000000 > GPR28: 00000001220a1c20 000000000000fff6 00000001220a30a0 0000000000100000 > [ 224.626325] NIP [00007fff95146770] 0x7fff95146770 > [ 224.626388] LR [00007fff95146770] 0x7fff95146770 > [ 224.626522] --- interrupt: 3000 > [ 224.626568] Instruction dump: > [ 224.626587] 60000000 813f000c 3929ffff 2c090000 913f000c 40820010 813f0074 71290004 > [ 224.626680] 4182074c 7fa3eb78 4bffda7d e93e0b10 <0b090000> e87e0a48 48c7dd0d 60000000 > [ 224.626786] ---[ end trace 0000000000000000 ]--- Does this ring a bell? Melvin, the same change went as well in other stable series, 6.6.88, 6.12.25, 6.14.4, can you test e.g. 6.12.25-1 in Debian as well from unstable to see if the regression is there as well? Might you be able to bisect the upstream stable series between 6.1.133 to 6.1.135 to really confirm the mentioned commit is the one breaking? Regards, Salvatore

4 months, 1 week

5
12
0 0

[PATCH v4 0/1] kasan: Avoid sleepable page allocation from atomic context

by Alexander Gordeev

Hi All, Chages since v3: - pfn_to_virt() changed to page_to_virt() due to compile error Chages since v2: - page allocation moved out of the atomic context Chages since v1: - Fixes: and -stable tags added to the patch description Thanks! Alexander Gordeev (1): kasan: Avoid sleepable page allocation from atomic context mm/kasan/shadow.c | 63 +++++++++++++++++++++++++++++++++++------------ 1 file changed, 47 insertions(+), 16 deletions(-) -- 2.45.2

4 months, 1 week

1
2
0 0

[PATCH v3 0/1] kasan: Avoid sleepable page allocation from atomic context

by Alexander Gordeev

Hi All, Chages since v2: - page allocation moved out of the atomic context Chages since v1: - Fixes: and -stable tags added to the patch description Thanks! Alexander Gordeev (1): kasan: Avoid sleepable page allocation from atomic context mm/kasan/shadow.c | 65 +++++++++++++++++++++++++++++++++++------------ 1 file changed, 49 insertions(+), 16 deletions(-) -- 2.45.2

4 months, 1 week

5
9
0 0

Re: G R A N T

by U N

Greetings Dear, Send your Ref: FSG2025 / Name / Phone Number / Country to Mr. Andrej Mahecic on un.grant(a)socialworker.net, +1 888 673 0430 for your £100,000.00. Sincerely Mr. C. Gunness On behalf of the UN.

4 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror