Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

301 participants
124138 discussions

+ codetag-debug-handle-existing-codetag_empty-in-mark_objexts_empty-for-slabobj_ext.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: codetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext has been added to the -mm mm-hotfixes-unstable branch. Its filename is codetag-debug-handle-existing-codetag_empty-in-mark_objexts_empty-for-slabobj_ext.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hao Ge <gehao(a)kylinos.cn> Subject: codetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext Date: Wed, 29 Oct 2025 09:43:17 +0800 When alloc_slab_obj_exts() fails and then later succeeds in allocating a slab extension vector, it calls handle_failed_objexts_alloc() to mark all objects in the vector as empty. As a result all objects in this slab (slabA) will have their extensions set to CODETAG_EMPTY. Later on if this slabA is used to allocate a slabobj_ext vector for another slab (slabB), we end up with the slabB->obj_exts pointing to a slabobj_ext vector that itself has a non-NULL slabobj_ext equal to CODETAG_EMPTY. When slabB gets freed, free_slab_obj_exts() is called to free slabB->obj_exts vector. free_slab_obj_exts() calls mark_objexts_empty(slabB->obj_exts) which will generate a warning because it expects slabobj_ext vectors to have a NULL obj_ext, not CODETAG_EMPTY. Modify mark_objexts_empty() to skip the warning and setting the obj_ext value if it's already set to CODETAG_EMPTY. To quickly detect this WARN, I modified the code from:WARN_ON(slab_exts[offs].ref.ct) to WARN_ON(slab_exts[offs].ref.ct == 1); We then obtained this message: [21630.898561] ------------[ cut here ]------------ [21630.898596] kernel BUG at mm/slub.c:2050! [21630.898611] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [21630.900372] Modules linked in: squashfs isofs vfio_iommu_type1 vhost_vsock vfio vhost_net vmw_vsock_virtio_transport_common vhost tap vhost_iotlb iommufd vsock binfmt_misc nfsv3 nfs_acl nfs lockd grace netfs tls rds dns_resolver tun brd overlay ntfs3 exfat btrfs blake2b_generic xor xor_neon raid6_pq loop sctp ip6_udp_tunnel udp_tunnel nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables rfkill ip_set sunrpc vfat fat joydev sg sch_fq_codel nfnetlink virtio_gpu sr_mod cdrom drm_client_lib virtio_dma_buf drm_shmem_helper drm_kms_helper drm ghash_ce backlight virtio_net virtio_blk virtio_scsi net_failover virtio_console failover virtio_mmio dm_mirror dm_region_hash dm_log dm_multipath dm_mod fuse i2c_dev virtio_pci virtio_pci_legacy_dev virtio_pci_modern_dev virtio virtio_ring autofs4 aes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject] [21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process-m Kdump: loaded Tainted: G�� W�� 6.18.0-rc1+ #74 PREEMPT(voluntary) [21630.910495] Tainted: [W]=WARN [21630.910867] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 [21630.911625] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [21630.912392] pc : __free_slab+0x228/0x250 [21630.912868] lr : __free_slab+0x18c/0x250[21630.913334] sp : ffff8000a02f73e0 [21630.913830] x29: ffff8000a02f73e0 x28: fffffdffc43fc800 x27: ffff0000c0011c40 [21630.914677] x26: ffff0000c000cac0 x25: ffff00010fe5e5f0 x24: ffff000102199b40 [21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21: ffff0000c0011c40 [21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18: 0000000000000000 [21630.917048] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [21630.917837] x14: 0000000000000000 x13: 0000000000000000 x12: ffff70001405ee66 [21630.918640] x11: 1ffff0001405ee65 x10: ffff70001405ee65 x9 : ffff800080a295dc [21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 : 0000000000003000 [21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 : 0000000000000007 [21630.921021] x2 : 0000000000001b40 x1 : 000000000000001f x0 : 0000000000000001 [21630.921810] Call trace: [21630.922130]�� __free_slab+0x228/0x250 (P) [21630.922669]�� free_slab+0x38/0x118 [21630.923079]�� free_to_partial_list+0x1d4/0x340 [21630.923591]�� __slab_free+0x24c/0x348 [21630.924024]�� ___cache_free+0xf0/0x110 [21630.924468]�� qlist_free_all+0x78/0x130 [21630.924922]�� kasan_quarantine_reduce+0x114/0x148 [21630.925525]�� __kasan_slab_alloc+0x7c/0xb0 [21630.926006]�� kmem_cache_alloc_noprof+0x164/0x5c8 [21630.926699]�� __alloc_object+0x44/0x1f8 [21630.927153]�� __create_object+0x34/0xc8 [21630.927604]�� kmemleak_alloc+0xb8/0xd8 [21630.928052]�� kmem_cache_alloc_noprof+0x368/0x5c8 [21630.928606]�� getname_flags.part.0+0xa4/0x610 [21630.929112]�� getname_flags+0x80/0xd8 [21630.929557]�� vfs_fstatat+0xc8/0xe0 [21630.929975]�� __do_sys_newfstatat+0xa0/0x100 [21630.930469]�� __arm64_sys_newfstatat+0x90/0xd8 [21630.931046]�� invoke_syscall+0xd4/0x258 [21630.931685]�� el0_svc_common.constprop.0+0xb4/0x240 [21630.932467]�� do_el0_svc+0x48/0x68 [21630.932972]�� el0_svc+0x40/0xe0 [21630.933472]�� el0t_64_sync_handler+0xa0/0xe8 [21630.934151]�� el0t_64_sync+0x1ac/0x1b0 [21630.934923] Code: aa1803e0 97ffef2b a9446bf9 17ffff9c (d4210000) [21630.936461] SMP: stopping secondary CPUs [21630.939550] Starting crashdump kernel... [21630.940108] Bye! Link: https://lkml.kernel.org/r/20251029014317.1533488-1-hao.ge@linux.dev Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations") Signed-off-by: Hao Ge <gehao(a)kylinos.cn> Cc: Christoph Lameter (Ampere) <cl(a)gentwo.org> Cc: David Rientjes <rientjes(a)google.com> Cc: gehao <gehao(a)kylinos.cn> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/slub.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/mm/slub.c~codetag-debug-handle-existing-codetag_empty-in-mark_objexts_empty-for-slabobj_ext +++ a/mm/slub.c @@ -2046,7 +2046,11 @@ static inline void mark_objexts_empty(st if (slab_exts) { unsigned int offs = obj_to_index(obj_exts_slab->slab_cache, obj_exts_slab, obj_exts); - /* codetag should be NULL */ + + if (unlikely(is_codetag_empty(&slab_exts[offs].ref))) + return; + + /* codetag should be NULL here */ WARN_ON(slab_exts[offs].ref.ct); set_codetag_empty(&slab_exts[offs].ref); } _ Patches currently in -mm which might be from gehao(a)kylinos.cn are codetag-debug-handle-existing-codetag_empty-in-mark_objexts_empty-for-slabobj_ext.patch

2 months, 2 weeks

Re: [PATCH] drm/mediatek: Disable AFBC support on Mediatek DRM driver

by Macpaul Lin (林智斌)

On Fri, 2025-10-24 at 17:27 -0300, Ariel D'Alessandro wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > > > Commit c410fa9b07c32 ("drm/mediatek: Add AFBC support to Mediatek DRM > driver") added AFBC support to Mediatek DRM and enabled the > 32x8/split/sparse modifier. > > However, this is currently broken on Mediatek MT8188 (Genio 700 EVK > platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is > used by > default since Mesa v25.0. > > Kernel trace reports vblank timeouts constantly, and the render is > garbled: > > ``` > [CRTC:62:crtc-0] vblank wait timed out > WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 > drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c > [...] > Hardware name: MediaTek Genio-700 EVK (DT) > Workqueue: events_unbound commit_work > pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) > pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c > lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c > sp : ffff80008337bca0 > x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000 > x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000 > x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80 > x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a > x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000 > x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b > x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70 > x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70 > x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480 > x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480 > Call trace: > drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P) > drm_atomic_helper_commit_tail_rpm+0x64/0x80 > commit_tail+0xa4/0x1a4 > commit_work+0x14/0x20 > process_one_work+0x150/0x290 > worker_thread+0x2d0/0x3ec > kthread+0x12c/0x210 > ret_from_fork+0x10/0x20 > ---[ end trace 0000000000000000 ]--- > ``` > > Until this gets fixed upstream, disable AFBC support on this > platform, as > it's currently broken with upstream Mesa. > > Signed-off-by: Ariel D'Alessandro <ariel.dalessandro(a)collabora.com> > --- > drivers/gpu/drm/mediatek/mtk_plane.c | 24 +----------------------- > 1 file changed, 1 insertion(+), 23 deletions(-) > > diff --git a/drivers/gpu/drm/mediatek/mtk_plane.c > b/drivers/gpu/drm/mediatek/mtk_plane.c > index 02349bd440017..788b52c1d10c5 100644 > --- a/drivers/gpu/drm/mediatek/mtk_plane.c > +++ b/drivers/gpu/drm/mediatek/mtk_plane.c > @@ -21,9 +21,6 @@ > > static const u64 modifiers[] = { > DRM_FORMAT_MOD_LINEAR, > - DRM_FORMAT_MOD_ARM_AFBC(AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 | > - AFBC_FORMAT_MOD_SPLIT | > - AFBC_FORMAT_MOD_SPARSE), > DRM_FORMAT_MOD_INVALID, > }; > > @@ -71,26 +68,7 @@ static bool mtk_plane_format_mod_supported(struct > drm_plane *plane, > uint32_t format, > uint64_t modifier) > { > - if (modifier == DRM_FORMAT_MOD_LINEAR) > - return true; > - > - if (modifier != DRM_FORMAT_MOD_ARM_AFBC( > - AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 | > - AFBC_FORMAT_MOD_SPLIT | > - AFBC_FORMAT_MOD_SPARSE)) > - return false; > - > - if (format != DRM_FORMAT_XRGB8888 && > - format != DRM_FORMAT_ARGB8888 && > - format != DRM_FORMAT_BGRX8888 && > - format != DRM_FORMAT_BGRA8888 && > - format != DRM_FORMAT_ABGR8888 && > - format != DRM_FORMAT_XBGR8888 && > - format != DRM_FORMAT_RGB888 && > - format != DRM_FORMAT_BGR888) > - return false; > - > - return true; > + return modifier == DRM_FORMAT_MOD_LINEAR; > } > > static void mtk_plane_destroy_state(struct drm_plane *plane, > Great! Thanks for this patch. I've tested this patch against k6.17.5 on mt8395-genio-1200-evk board, and it is working. I've also tested this patch with 'modetest -M mediatek -s 34@59:1200x1290' is working as well. I'm not sure if it is possible to add a "Fixes:" tag to this patch? Maybe add this patch with 'Cc: stable(a)vger.kernel.org #6.17' at least? Some Linux distros are currently using 6.17 for testing. Reviewed-by: Macpaul Lin <macpaul.lin(a)mediatek.com> Regards, Macpaul Lin

2 months, 2 weeks

[PATCH v2 1/1] Bluetooth: btusb: add default nvm file

by Shuai Zhang

If no NVM file matches the board_id, load the default NVM file. Signed-off-by: Shuai Zhang <quic_shuaz(a)quicinc.com> Cc: stable(a)vger.kernel.org --- drivers/bluetooth/btusb.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index dcbff7641..6903606d3 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -3482,15 +3482,14 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev *hdev, } static void btusb_generate_qca_nvm_name(char *fwname, size_t max_size, - const struct qca_version *ver) + const struct qca_version *ver, + u16 board_id) { u32 rom_version = le32_to_cpu(ver->rom_version); const char *variant, *fw_subdir; int len; - u16 board_id; fw_subdir = qca_get_fw_subdirectory(ver); - board_id = qca_extract_board_id(ver); switch (le32_to_cpu(ver->ram_version)) { case WCN6855_2_0_RAM_VERSION_GF: @@ -3522,14 +3521,28 @@ static int btusb_setup_qca_load_nvm(struct hci_dev *hdev, const struct firmware *fw; char fwname[80]; int err; + u16 board_id = 0; - btusb_generate_qca_nvm_name(fwname, sizeof(fwname), ver); + board_id = qca_extract_board_id(ver); +retry: + btusb_generate_qca_nvm_name(fwname, sizeof(fwname), ver, board_id); err = request_firmware(&fw, fwname, &hdev->dev); if (err) { + if (err == -EINVAL) { + bt_dev_err(hdev, "QCOM BT firmware file request failed (%d)", err); + return err; + } + bt_dev_err(hdev, "failed to request NVM file: %s (%d)", fwname, err); - return err; + if (err == -ENOENT && board_id != 0) { + board_id = 0; + goto retry; + } else { + bt_dev_err(hdev, "QCOM BT firmware file request failed (%d)", err); + return err; + } } bt_dev_info(hdev, "using NVM file: %s", fwname); -- 2.34.1

2 months, 2 weeks

[PATCH v1] Bluetooth: btusb: add default nvm file

by Shuai Zhang

If no NVM file matches the board_id, load the default NVM file. Signed-off-by: Shuai Zhang <quic_shuaz(a)quicinc.com> --- drivers/bluetooth/btusb.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index dcbff7641..998dfd455 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -3482,15 +3482,14 @@ static int btusb_setup_qca_load_rampatch(struct hci_dev *hdev, } static void btusb_generate_qca_nvm_name(char *fwname, size_t max_size, - const struct qca_version *ver) + const struct qca_version *ver, + u16 board_id) { u32 rom_version = le32_to_cpu(ver->rom_version); const char *variant, *fw_subdir; int len; - u16 board_id; fw_subdir = qca_get_fw_subdirectory(ver); - board_id = qca_extract_board_id(ver); switch (le32_to_cpu(ver->ram_version)) { case WCN6855_2_0_RAM_VERSION_GF: @@ -3522,13 +3521,25 @@ static int btusb_setup_qca_load_nvm(struct hci_dev *hdev, const struct firmware *fw; char fwname[80]; int err; + u16 board_id = 0; - btusb_generate_qca_nvm_name(fwname, sizeof(fwname), ver); + board_id = qca_extract_board_id(ver); +retry: + btusb_generate_qca_nvm_name(fwname, sizeof(fwname), ver, board_id); err = request_firmware(&fw, fwname, &hdev->dev); if (err) { + if (err == -EINVAL) { + bt_dev_err(hdev, "QCOM BT firmware file request failed (%d)", err); + return err; + } + bt_dev_err(hdev, "failed to request NVM file: %s (%d)", fwname, err); + if (err == -ENOENT && board_id != 0) { + board_id = 0; + goto retry; + } return err; } -- 2.34.1

2 months, 2 weeks

Inquiry about purchasing your products

by PERDIS SUPER U

-- Hi, PERDIS SUPER U is a leading retail group in France with numerous outlets across the country. After reviewing your company profile and products, we’re very interested in establishing a long-term partnership. Kindly share your product catalog or website so we can review your offerings and pricing. We are ready to place orders and begin cooperation.Please note: Our payment terms are SWIFT, 14 days after delivery. Looking forward to your response. Best regards, Dominique Schelcher Director, PERDIS SUPER U RUE DE SAVOIE, 45600 SAINT-PÈRE-SUR-LOIRE VAT: FR65380071464 www.magasins-u.com

2 months, 2 weeks

+ mm-mremap-honour-writable-bit-in-mremap-pte-batching.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/mremap: honour writable bit in mremap pte batching has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-mremap-honour-writable-bit-in-mremap-pte-batching.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Dev Jain <dev.jain(a)arm.com> Subject: mm/mremap: honour writable bit in mremap pte batching Date: Tue, 28 Oct 2025 12:09:52 +0530 Currently mremap folio pte batch ignores the writable bit during figuring out a set of similar ptes mapping the same folio. Suppose that the first pte of the batch is writable while the others are not - set_ptes will end up setting the writable bit on the other ptes, which is a violation of mremap semantics. Therefore, use FPB_RESPECT_WRITE to check the writable bit while determining the pte batch. Link: https://lkml.kernel.org/r/20251028063952.90313-1-dev.jain@arm.com Signed-off-by: Dev Jain <dev.jain(a)arm.com> Fixes: f822a9a81a31 ("mm: optimize mremap() by PTE batching") Reported-by: David Hildenbrand <david(a)redhat.com> Debugged-by: David Hildenbrand <david(a)redhat.com> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: Pedro Falcato <pfalcato(a)suse.de> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Barry Song <baohua(a)kernel.org> Cc: Jann Horn <jannh(a)google.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> [6.17+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mremap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/mremap.c~mm-mremap-honour-writable-bit-in-mremap-pte-batching +++ a/mm/mremap.c @@ -187,7 +187,7 @@ static int mremap_folio_pte_batch(struct if (!folio || !folio_test_large(folio)) return 1; - return folio_pte_batch(folio, ptep, pte, max_nr); + return folio_pte_batch_flags(folio, NULL, ptep, &pte, max_nr, FPB_RESPECT_WRITE); } static int move_ptes(struct pagetable_move_control *pmc, _ Patches currently in -mm which might be from dev.jain(a)arm.com are mm-mremap-honour-writable-bit-in-mremap-pte-batching.patch

2 months, 2 weeks

+ gcov-add-support-for-gcc-15.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: gcov: add support for GCC 15 has been added to the -mm mm-hotfixes-unstable branch. Its filename is gcov-add-support-for-gcc-15.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Peter Oberparleiter <oberpar(a)linux.ibm.com> Subject: gcov: add support for GCC 15 Date: Tue, 28 Oct 2025 12:51:25 +0100 Using gcov on kernels compiled with GCC 15 results in truncated 16-byte long .gcda files with no usable data. To fix this, update GCOV_COUNTERS to match the value defined by GCC 15. Tested with GCC 14.3.0 and GCC 15.2.0. Link: https://lkml.kernel.org/r/20251028115125.1319410-1-oberpar@linux.ibm.com Signed-off-by: Peter Oberparleiter <oberpar(a)linux.ibm.com> Reported-by: Matthieu Baerts <matttbe(a)kernel.org> Closes: https://github.com/linux-test-project/lcov/issues/445 Tested-by: Matthieu Baerts <matttbe(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/gcov/gcc_4_7.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/kernel/gcov/gcc_4_7.c~gcov-add-support-for-gcc-15 +++ a/kernel/gcov/gcc_4_7.c @@ -18,7 +18,9 @@ #include <linux/mm.h> #include "gcov.h" -#if (__GNUC__ >= 14) +#if (__GNUC__ >= 15) +#define GCOV_COUNTERS 10 +#elif (__GNUC__ >= 14) #define GCOV_COUNTERS 9 #elif (__GNUC__ >= 10) #define GCOV_COUNTERS 8 _ Patches currently in -mm which might be from oberpar(a)linux.ibm.com are gcov-add-support-for-gcc-15.patch

2 months, 2 weeks

+ s390-fix-hugetlb-vmemmap-optimization-crash.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: s390: fix HugeTLB vmemmap optimization crash has been added to the -mm mm-hotfixes-unstable branch. Its filename is s390-fix-hugetlb-vmemmap-optimization-crash.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Luiz Capitulino <luizcap(a)redhat.com> Subject: s390: fix HugeTLB vmemmap optimization crash Date: Tue, 28 Oct 2025 17:15:33 -0400 A reproducible crash occurs when enabling HugeTLB vmemmap optimization (HVO) on s390. The crash and the proposed fix were worked on an s390 KVM guest running on an older hypervisor, as I don't have access to an LPAR. However, the same issue should occur on bare-metal. Reproducer (it may take a few runs to trigger): # sysctl vm.hugetlb_optimize_vmemmap=1 # echo 1 > /proc/sys/vm/nr_hugepages # echo 0 > /proc/sys/vm/nr_hugepages Crash log: [ 52.340369] list_del corruption. prev->next should be 000000d382110008, but was 000000d7116d3880. (prev=000000d7116d3910) [ 52.340420] ------------[ cut here ]------------ [ 52.340424] kernel BUG at lib/list_debug.c:62! [ 52.340566] monitor event: 0040 ilc:2 [#1]SMP [ 52.340573] Modules linked in: ctcm fsm qeth ccwgroup zfcp scsi_transport_fc qdio dasd_fba_mod dasd_eckd_mod dasd_mod xfs ghash_s390 prng des_s390 libdes sha3_512_s390 sha3_256_s390 virtio_net virtio_blk net_failover sha_common failover dm_mirror dm_region_hash dm_log dm_mod paes_s390 crypto_engine pkey_cca pkey_ep11 zcrypt pkey_pckmo pkey aes_s390 [ 52.340606] CPU: 1 UID: 0 PID: 1672 Comm: root-rep2 Kdump: loaded Not tainted 6.18.0-rc3 #1 NONE [ 52.340610] Hardware name: IBM 3931 LA1 400 (KVM/Linux) [ 52.340611] Krnl PSW : 0704c00180000000 0000015710cda7fe (__list_del_entry_valid_or_report+0xfe/0x128) [ 52.340619] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 [ 52.340622] Krnl GPRS: c0000000ffffefff 0000000100000027 000000000000006d 0000000000000000 [ 52.340623] 000000d7116d35d8 000000d7116d35d0 0000000000000002 000000d7116d39b0 [ 52.340625] 000000d7116d3880 000000d7116d3910 000000d7116d3910 000000d382110008 [ 52.340626] 000003ffac1ccd08 000000d7116d39b0 0000015710cda7fa 000000d7116d37d0 [ 52.340632] Krnl Code: 0000015710cda7ee: c020003e496f larl %r2,00000157114a3acc 0000015710cda7f4: c0e5ffd5280e brasl %r14,000001571077f810 #0000015710cda7fa: af000000 mc 0,0 >0000015710cda7fe: b9040029 lgr %r2,%r9 0000015710cda802: c0e5ffe5e193 brasl %r14,0000015710996b28 0000015710cda808: e34090080004 lg %r4,8(%r9) 0000015710cda80e: b9040059 lgr %r5,%r9 0000015710cda812: b9040038 lgr %r3,%r8 [ 52.340643] Call Trace: [ 52.340645] [<0000015710cda7fe>] __list_del_entry_valid_or_report+0xfe/0x128 [ 52.340649] ([<0000015710cda7fa>] __list_del_entry_valid_or_report+0xfa/0x128) [ 52.340652] [<0000015710a30b2e>] hugetlb_vmemmap_restore_folios+0x96/0x138 [ 52.340655] [<0000015710a268ac>] update_and_free_pages_bulk+0x64/0x150 [ 52.340659] [<0000015710a26f8a>] set_max_huge_pages+0x4ca/0x6f0 [ 52.340662] [<0000015710a273ba>] hugetlb_sysctl_handler_common+0xea/0x120 [ 52.340665] [<0000015710a27484>] hugetlb_sysctl_handler+0x44/0x50 [ 52.340667] [<0000015710b53ffa>] proc_sys_call_handler+0x17a/0x280 [ 52.340672] [<0000015710a90968>] vfs_write+0x2c8/0x3a0 [ 52.340676] [<0000015710a90bd2>] ksys_write+0x72/0x100 [ 52.340679] [<00000157111483a8>] __do_syscall+0x150/0x318 [ 52.340682] [<0000015711153a5e>] system_call+0x6e/0x90 [ 52.340684] Last Breaking-Event-Address: [ 52.340684] [<000001571077f85c>] _printk+0x4c/0x58 [ 52.340690] Kernel panic - not syncing: Fatal exception: panic_on_oops This issue was introduced by commit f13b83fdd996 ("hugetlb: batch TLB flushes when freeing vmemmap"). Before that change, the HVO implementation called flush_tlb_kernel_range() each time a vmemmap PMD split and remapping was performed. The mentioned commit changed this to issue a few flush_tlb_all() calls after performing all remappings. However, on s390, flush_tlb_kernel_range() expands to __tlb_flush_kernel() while flush_tlb_all() is not implemented. As a result, we went from flushing the TLB for every remapping to no flushing at all. This commit fixes this by implementing flush_tlb_all() on s390 as an alias to __tlb_flush_global(). This should cause a flush on all TLB entries on all CPUs as expected by the flush_tlb_all() semantics. Link: https://lkml.kernel.org/r/20251028211533.47694-1-luizcap@redhat.com Fixes: f13b83fdd996 ("hugetlb: batch TLB flushes when freeing vmemmap") Signed-off-by: Luiz Capitulino <luizcap(a)redhat.com> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar(a)kernel.org> Cc: Christian Borntraeger <borntraeger(a)linux.ibm.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Joao Martins <joao.m.martins(a)oracle.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/s390/include/asm/tlbflush.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/arch/s390/include/asm/tlbflush.h~s390-fix-hugetlb-vmemmap-optimization-crash +++ a/arch/s390/include/asm/tlbflush.h @@ -103,9 +103,13 @@ static inline void __tlb_flush_mm_lazy(s * flush_tlb_range functions need to do the flush. */ #define flush_tlb() do { } while (0) -#define flush_tlb_all() do { } while (0) #define flush_tlb_page(vma, addr) do { } while (0) +static inline void flush_tlb_all(void) +{ + __tlb_flush_global(); +} + static inline void flush_tlb_mm(struct mm_struct *mm) { __tlb_flush_mm_lazy(mm); _ Patches currently in -mm which might be from luizcap(a)redhat.com are s390-fix-hugetlb-vmemmap-optimization-crash.patch

2 months, 2 weeks

[PATCH] video: valkyriefb: Fix reference count leak in valkyriefb_init

by Miaoqian Lin

The of_find_node_by_name() function returns a device tree node with its reference count incremented. The caller is responsible for calling of_node_put() to release this reference when done. Found via static analysis. Fixes: cc5d0189b9ba ("[PATCH] powerpc: Remove device_node addrs/n_addr") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/video/fbdev/valkyriefb.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/video/fbdev/valkyriefb.c b/drivers/video/fbdev/valkyriefb.c index 91d070ef6989..6ff059ee1694 100644 --- a/drivers/video/fbdev/valkyriefb.c +++ b/drivers/video/fbdev/valkyriefb.c @@ -329,11 +329,13 @@ static int __init valkyriefb_init(void) if (of_address_to_resource(dp, 0, &r)) { printk(KERN_ERR "can't find address for valkyrie\n"); + of_node_put(dp); return 0; } frame_buffer_phys = r.start; cmap_regs_phys = r.start + 0x304000; + of_node_put(dp); } #endif /* ppc (!CONFIG_MAC) */ -- 2.39.5 (Apple Git-154)

2 months, 2 weeks

+ codetag-debug-handle-existing-codetag_empty-in-mark_objexts_empty-for-slabobj_ext.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: codetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext has been added to the -mm mm-new branch. Its filename is codetag-debug-handle-existing-codetag_empty-in-mark_objexts_empty-for-slabobj_ext.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hao Ge <gehao(a)kylinos.cn> Subject: codetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext Date: Mon, 27 Oct 2025 16:52:14 +0800 Even though obj_exts was created with the __GFP_NO_OBJ_EXT flag, objects in the same slab may have their extensions allocated via alloc_slab_obj_exts, and handle_failed_objexts_alloc may be called within alloc_slab_obj_exts to set their codetag to CODETAG_EMPTY. Therefore, both NULL and CODETAG_EMPTY are valid for the codetag of slabobj_ext, as we do not need to re-set it to CODETAG_EMPTY if it is already CODETAG_EMPTY. It also resolves the warning triggered when the codetag is CODETAG_EMPTY during slab freeing. This issue also occurred during our memory stress testing. The possibility of its occurrence should be as follows: When a slab allocates a slabobj_ext, the slab to which this slabobj_ext belongs may have already allocated its own slabobj_ext and called handle_failed_objexts_alloc. That is to say, the codetag of this slabobj_ext has been set to CODETAG_EMPTY. To quickly detect this WARN, I modified the code from:WARN_ON(slab_exts[offs].ref.ct) to WARN_ON(slab_exts[offs].ref.ct == 1); We then obtained this message: [21630.898561] ------------[ cut here ]------------ [21630.898596] kernel BUG at mm/slub.c:2050! [21630.898611] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [21630.900372] Modules linked in: squashfs isofs vfio_iommu_type1 vhost_vsock vfio vhost_net vmw_vsock_virtio_transport_common vhost tap vhost_iotlb iommufd vsock binfmt_misc nfsv3 nfs_acl nfs lockd grace netfs tls rds dns_resolver tun brd overlay ntfs3 exfat btrfs blake2b_generic xor xor_neon raid6_pq loop sctp ip6_udp_tunnel udp_tunnel nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables rfkill ip_set sunrpc vfat fat joydev sg sch_fq_codel nfnetlink virtio_gpu sr_mod cdrom drm_client_lib virtio_dma_buf drm_shmem_helper drm_kms_helper drm ghash_ce backlight virtio_net virtio_blk virtio_scsi net_failover virtio_console failover virtio_mmio dm_mirror dm_region_hash dm_log dm_multipath dm_mod fuse i2c_dev virtio_pci virtio_pci_legacy_dev virtio_pci_modern_dev virtio virtio_ring autofs4 aes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject] [21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process-m Kdump: loaded Tainted: G�� W�� 6.18.0-rc1+ #74 PREEMPT(voluntary) [21630.910495] Tainted: [W]=WARN [21630.910867] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 [21630.911625] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [21630.912392] pc : __free_slab+0x228/0x250 [21630.912868] lr : __free_slab+0x18c/0x250[21630.913334] sp : ffff8000a02f73e0 [21630.913830] x29: ffff8000a02f73e0 x28: fffffdffc43fc800 x27: ffff0000c0011c40 [21630.914677] x26: ffff0000c000cac0 x25: ffff00010fe5e5f0 x24: ffff000102199b40 [21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21: ffff0000c0011c40 [21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18: 0000000000000000 [21630.917048] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [21630.917837] x14: 0000000000000000 x13: 0000000000000000 x12: ffff70001405ee66 [21630.918640] x11: 1ffff0001405ee65 x10: ffff70001405ee65 x9 : ffff800080a295dc [21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 : 0000000000003000 [21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 : 0000000000000007 [21630.921021] x2 : 0000000000001b40 x1 : 000000000000001f x0 : 0000000000000001 [21630.921810] Call trace: [21630.922130]�� __free_slab+0x228/0x250 (P) [21630.922669]�� free_slab+0x38/0x118 [21630.923079]�� free_to_partial_list+0x1d4/0x340 [21630.923591]�� __slab_free+0x24c/0x348 [21630.924024]�� ___cache_free+0xf0/0x110 [21630.924468]�� qlist_free_all+0x78/0x130 [21630.924922]�� kasan_quarantine_reduce+0x114/0x148 [21630.925525]�� __kasan_slab_alloc+0x7c/0xb0 [21630.926006]�� kmem_cache_alloc_noprof+0x164/0x5c8 [21630.926699]�� __alloc_object+0x44/0x1f8 [21630.927153]�� __create_object+0x34/0xc8 [21630.927604]�� kmemleak_alloc+0xb8/0xd8 [21630.928052]�� kmem_cache_alloc_noprof+0x368/0x5c8 [21630.928606]�� getname_flags.part.0+0xa4/0x610 [21630.929112]�� getname_flags+0x80/0xd8 [21630.929557]�� vfs_fstatat+0xc8/0xe0 [21630.929975]�� __do_sys_newfstatat+0xa0/0x100 [21630.930469]�� __arm64_sys_newfstatat+0x90/0xd8 [21630.931046]�� invoke_syscall+0xd4/0x258 [21630.931685]�� el0_svc_common.constprop.0+0xb4/0x240 [21630.932467]�� do_el0_svc+0x48/0x68 [21630.932972]�� el0_svc+0x40/0xe0 [21630.933472]�� el0t_64_sync_handler+0xa0/0xe8 [21630.934151]�� el0t_64_sync+0x1ac/0x1b0 [21630.934923] Code: aa1803e0 97ffef2b a9446bf9 17ffff9c (d4210000) [21630.936461] SMP: stopping secondary CPUs [21630.939550] Starting crashdump kernel... [21630.940108] Bye! Link: https://lkml.kernel.org/r/20251027085214.184672-1-hao.ge@linux.dev Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations") Signed-off-by: Hao Ge <gehao(a)kylinos.cn> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Christoph Lameter (Ampere) <cl(a)gentwo.org> Cc: David Rientjes <rientjes(a)google.com> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/slub.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/mm/slub.c~codetag-debug-handle-existing-codetag_empty-in-mark_objexts_empty-for-slabobj_ext +++ a/mm/slub.c @@ -2046,7 +2046,17 @@ static inline void mark_objexts_empty(st if (slab_exts) { unsigned int offs = obj_to_index(obj_exts_slab->slab_cache, obj_exts_slab, obj_exts); - /* codetag should be NULL */ + + /* + * codetag should be either NULL or CODETAG_EMPTY. + * When the same slab calls handle_failed_objexts_alloc, + * it will set us to CODETAG_EMPTY. + * + * If codetag is already CODETAG_EMPTY, no action is needed here. + */ + if (unlikely(is_codetag_empty(&slab_exts[offs].ref))) + return; + WARN_ON(slab_exts[offs].ref.ct); set_codetag_empty(&slab_exts[offs].ref); } _ Patches currently in -mm which might be from gehao(a)kylinos.cn are codetag-debug-handle-existing-codetag_empty-in-mark_objexts_empty-for-slabobj_ext.patch

2 months, 2 weeks

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror