Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

277 participants
124110 discussions

[PATCH v2] codetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext

by Hao Ge

From: Hao Ge <gehao(a)kylinos.cn> 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. Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations") Cc: <stable(a)vger.kernel.org> Signed-off-by: Hao Ge <gehao(a)kylinos.cn> --- v2: Update the commit message and code comments for greater accuracy, incorporating Suren's suggestions. Thanks for Suren's help. --- mm/slub.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/mm/slub.c b/mm/slub.c index d4367f25b20d..589c596163c4 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2046,7 +2046,11 @@ static inline void mark_objexts_empty(struct slabobj_ext *obj_exts) 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); } -- 2.25.1

2 months, 1 week

+ 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, 1 week

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, 1 week

[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, 1 week

[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, 1 week

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, 1 week

+ 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, 1 week

+ 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, 1 week

+ 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, 1 week

[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, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror