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

[regression] 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY") causes issue with ID 4c4a:4155 Jieli Technology USB Composite Device

by Salvatore Bonaccorso

Hi Zhang, hi Jiri, In Debian Staffan Melin reported that after an update containing the commit 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY"), the input device with same idVendor and idProduct, the Jieli Technology USB Composite Device, does not get recognized anymore. The full Debian report is at: https://bugs.debian.org/1114557 The issue is not specific to the 6.12.y series and confirmed in 6.16.3 as well. Staffan Melin did bisect the kernels between 6.12.38 (which was still working) and 6.1.41 (which was not), confirming by bisection that the offending commit is 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY") #regzbot introduced: 1a8953f4f774 #regzbot monitor: https://bugs.debian.org/1114557 So it looks that the quirk applied is unfortunately affecting negatively as well Staffan Melin case. Can you have a look? Regards, Salvatore

1 month

5
14
0 0

[merged mm-stable] mm-swap-check-for-stable-address-space-before-operating-on-the-vma.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: swap: check for stable address space before operating on the VMA has been removed from the -mm tree. Its filename was mm-swap-check-for-stable-address-space-before-operating-on-the-vma.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Charan Teja Kalla <charan.kalla(a)oss.qualcomm.com> Subject: mm: swap: check for stable address space before operating on the VMA Date: Wed, 24 Sep 2025 23:41:38 +0530 It is possible to hit a zero entry while traversing the vmas in unuse_mm() called from swapoff path and accessing it causes the OOPS: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000446--> Loading the memory from offset 0x40 on the XA_ZERO_ENTRY as address. Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault The issue is manifested from the below race between the fork() on a process and swapoff: fork(dup_mmap()) swapoff(unuse_mm) --------------- ----------------- 1) Identical mtree is built using __mt_dup(). 2) copy_pte_range()--> copy_nonpresent_pte(): The dst mm is added into the mmlist to be visible to the swapoff operation. 3) Fatal signal is sent to the parent process(which is the current during the fork) thus skip the duplication of the vmas and mark the vma range with XA_ZERO_ENTRY as a marker for this process that helps during exit_mmap(). 4) swapoff is tried on the 'mm' added to the 'mmlist' as part of the 2. 5) unuse_mm(), that iterates through the vma's of this 'mm' will hit the non-NULL zero entry and operating on this zero entry as a vma is resulting into the oops. The proper fix would be around not exposing this partially-valid tree to others when droping the mmap lock, which is being solved with [1]. A simpler solution would be checking for MMF_UNSTABLE, as it is set if mm_struct is not fully initialized in dup_mmap(). Thanks to Liam/Lorenzo/David for all the suggestions in fixing this issue. Link: https://lkml.kernel.org/r/20250924181138.1762750-1-charan.kalla@oss.qualcom… Link: https://lore.kernel.org/all/20250815191031.3769540-1-Liam.Howlett@oracle.co… [1] Fixes: d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") Signed-off-by: Charan Teja Kalla <charan.kalla(a)oss.qualcomm.com> Suggested-by: David Hildenbrand <david(a)redhat.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Barry Song <baohua(a)kernel.org> Cc: Chris Li <chrisl(a)kernel.org> Cc: Kairui Song <kasong(a)tencent.com> Cc: Kemeng Shi <shikemeng(a)huaweicloud.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Nhat Pham <nphamcs(a)gmail.com> Cc: Peng Zhang <zhangpeng.00(a)bytedance.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/swapfile.c | 3 +++ 1 file changed, 3 insertions(+) --- a/mm/swapfile.c~mm-swap-check-for-stable-address-space-before-operating-on-the-vma +++ a/mm/swapfile.c @@ -2389,6 +2389,8 @@ static int unuse_mm(struct mm_struct *mm VMA_ITERATOR(vmi, mm, 0); mmap_read_lock(mm); + if (check_stable_address_space(mm)) + goto unlock; for_each_vma(vmi, vma) { if (vma->anon_vma && !is_vm_hugetlb_page(vma)) { ret = unuse_vma(vma, type); @@ -2398,6 +2400,7 @@ static int unuse_mm(struct mm_struct *mm cond_resched(); } +unlock: mmap_read_unlock(mm); return ret; } _ Patches currently in -mm which might be from charan.kalla(a)oss.qualcomm.com are

1 month

1
0
0 0

[merged mm-stable] mm-ksm-fix-incorrect-ksm-counter-handling-in-mm_struct-during-fork.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/ksm: fix incorrect KSM counter handling in mm_struct during fork has been removed from the -mm tree. Its filename was mm-ksm-fix-incorrect-ksm-counter-handling-in-mm_struct-during-fork.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Donet Tom <donettom(a)linux.ibm.com> Subject: mm/ksm: fix incorrect KSM counter handling in mm_struct during fork Date: Wed, 24 Sep 2025 00:16:59 +0530 Patch series "mm/ksm: Fix incorrect accounting of KSM counters during fork", v3. The first patch in this series fixes the incorrect accounting of KSM counters such as ksm_merging_pages, ksm_rmap_items, and the global ksm_zero_pages during fork. The following patch add a selftest to verify the ksm_merging_pages counter was updated correctly during fork. Test Results ============ Without the first patch ----------------------- # [RUN] test_fork_ksm_merging_page_count not ok 10 ksm_merging_page in child: 32 With the first patch -------------------- # [RUN] test_fork_ksm_merging_page_count ok 10 ksm_merging_pages is not inherited after fork This patch (of 2): Currently, the KSM-related counters in `mm_struct`, such as `ksm_merging_pages`, `ksm_rmap_items`, and `ksm_zero_pages`, are inherited by the child process during fork. This results in inconsistent accounting. When a process uses KSM, identical pages are merged and an rmap item is created for each merged page. The `ksm_merging_pages` and `ksm_rmap_items` counters are updated accordingly. However, after a fork, these counters are copied to the child while the corresponding rmap items are not. As a result, when the child later triggers an unmerge, there are no rmap items present in the child, so the counters remain stale, leading to incorrect accounting. A similar issue exists with `ksm_zero_pages`, which maintains both a global counter and a per-process counter. During fork, the per-process counter is inherited by the child, but the global counter is not incremented. Since the child also references zero pages, the global counter should be updated as well. Otherwise, during zero-page unmerge, both the global and per-process counters are decremented, causing the global counter to become inconsistent. To fix this, ksm_merging_pages and ksm_rmap_items are reset to 0 during fork, and the global ksm_zero_pages counter is updated with the per-process ksm_zero_pages value inherited by the child. This ensures that KSM statistics remain accurate and reflect the activity of each process correctly. Link: https://lkml.kernel.org/r/cover.1758648700.git.donettom@linux.ibm.com Link: https://lkml.kernel.org/r/7b9870eb67ccc0d79593940d9dbd4a0b39b5d396.17586487… Fixes: 7609385337a4 ("ksm: count ksm merging pages for each process") Fixes: cb4df4cae4f2 ("ksm: count allocated ksm rmap_items for each process") Fixes: e2942062e01d ("ksm: count all zero pages placed by KSM") Signed-off-by: Donet Tom <donettom(a)linux.ibm.com> Reviewed-by: Chengming Zhou <chengming.zhou(a)linux.dev> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Aboorva Devarajan <aboorvad(a)linux.ibm.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Donet Tom <donettom(a)linux.ibm.com> Cc: "Ritesh Harjani (IBM)" <ritesh.list(a)gmail.com> Cc: Wei Yang <richard.weiyang(a)gmail.com> Cc: xu xin <xu.xin16(a)zte.com.cn> Cc: <stable(a)vger.kernel.org> [6.6+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/ksm.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/include/linux/ksm.h~mm-ksm-fix-incorrect-ksm-counter-handling-in-mm_struct-during-fork +++ a/include/linux/ksm.h @@ -56,8 +56,14 @@ static inline long mm_ksm_zero_pages(str static inline void ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm) { /* Adding mm to ksm is best effort on fork. */ - if (mm_flags_test(MMF_VM_MERGEABLE, oldmm)) + if (mm_flags_test(MMF_VM_MERGEABLE, oldmm)) { + long nr_ksm_zero_pages = atomic_long_read(&mm->ksm_zero_pages); + + mm->ksm_merging_pages = 0; + mm->ksm_rmap_items = 0; + atomic_long_add(nr_ksm_zero_pages, &ksm_zero_pages); __ksm_enter(mm); + } } static inline int ksm_execve(struct mm_struct *mm) _ Patches currently in -mm which might be from donettom(a)linux.ibm.com are

1 month

1
0
0 0

[merged mm-nonmm-stable] squashfs-reject-negative-file-sizes-in-squashfs_read_inode.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: Squashfs: reject negative file sizes in squashfs_read_inode() has been removed from the -mm tree. Its filename was squashfs-reject-negative-file-sizes-in-squashfs_read_inode.patch This patch was dropped because it was merged into the mm-nonmm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Phillip Lougher <phillip(a)squashfs.org.uk> Subject: Squashfs: reject negative file sizes in squashfs_read_inode() Date: Fri, 26 Sep 2025 22:59:35 +0100 Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size. This commit checks for a negative file size and returns EINVAL. [phillip(a)squashfs.org.uk: only need to check 64 bit quantity] Link: https://lkml.kernel.org/r/20250926222305.110103-1-phillip@squashfs.org.uk Link: https://lkml.kernel.org/r/20250926215935.107233-1-phillip@squashfs.org.uk Fixes: 6545b246a2c8 ("Squashfs: inode operations") Signed-off-by: Phillip Lougher <phillip(a)squashfs.org.uk> Reported-by: syzbot+f754e01116421e9754b9(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68d580e5.a00a0220.303701.0019.GAE@google.com/ Cc: Amir Goldstein <amir73il(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/squashfs/inode.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/fs/squashfs/inode.c~squashfs-reject-negative-file-sizes-in-squashfs_read_inode +++ a/fs/squashfs/inode.c @@ -197,6 +197,10 @@ int squashfs_read_inode(struct inode *in goto failed_read; inode->i_size = le64_to_cpu(sqsh_ino->file_size); + if (inode->i_size < 0) { + err = -EINVAL; + goto failed_read; + } frag = le32_to_cpu(sqsh_ino->fragment); if (frag != SQUASHFS_INVALID_FRAG) { /* _ Patches currently in -mm which might be from phillip(a)squashfs.org.uk are

1 month

1
0
0 0

[merged mm-nonmm-stable] lib-genalloc-fix-device-leak-in-of_gen_pool_get.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: lib/genalloc: fix device leak in of_gen_pool_get() has been removed from the -mm tree. Its filename was lib-genalloc-fix-device-leak-in-of_gen_pool_get.patch This patch was dropped because it was merged into the mm-nonmm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Johan Hovold <johan(a)kernel.org> Subject: lib/genalloc: fix device leak in of_gen_pool_get() Date: Wed, 24 Sep 2025 10:02:07 +0200 Make sure to drop the reference taken when looking up the genpool platform device in of_gen_pool_get() before returning the pool. Note that holding a reference to a device does typically not prevent its devres managed resources from being released so there is no point in keeping the reference. Link: https://lkml.kernel.org/r/20250924080207.18006-1-johan@kernel.org Fixes: 9375db07adea ("genalloc: add devres support, allow to find a managed pool by device") Signed-off-by: Johan Hovold <johan(a)kernel.org> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Vladimir Zapolskiy <vz(a)mleia.com> Cc: <stable(a)vger.kernel.org> [3.10+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/genalloc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/lib/genalloc.c~lib-genalloc-fix-device-leak-in-of_gen_pool_get +++ a/lib/genalloc.c @@ -899,8 +899,11 @@ struct gen_pool *of_gen_pool_get(struct if (!name) name = of_node_full_name(np_pool); } - if (pdev) + if (pdev) { pool = gen_pool_get(&pdev->dev, name); + put_device(&pdev->dev); + } + of_node_put(np_pool); return pool; _ Patches currently in -mm which might be from johan(a)kernel.org are

1 month

1
0
0 0

[merged mm-nonmm-stable] squashfs-fix-uninit-value-in-squashfs_get_parent.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: Squashfs: fix uninit-value in squashfs_get_parent has been removed from the -mm tree. Its filename was squashfs-fix-uninit-value-in-squashfs_get_parent.patch This patch was dropped because it was merged into the mm-nonmm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Phillip Lougher <phillip(a)squashfs.org.uk> Subject: Squashfs: fix uninit-value in squashfs_get_parent Date: Fri, 19 Sep 2025 00:33:08 +0100 Syzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug. This is caused by open_by_handle_at() being called with a file handle containing an invalid parent inode number. In particular the inode number is that of a symbolic link, rather than a directory. Squashfs_get_parent() gets called with that symbolic link inode, and accesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent; Because non-directory inodes in Squashfs do not have a parent value, this is uninitialised, and this causes an uninitialised value access. The fix is to initialise parent with the invalid inode 0, which will cause an EINVAL error to be returned. Regular inodes used to share the parent field with the block_list_start field. This is removed in this commit to enable the parent field to contain the invalid inode number 0. Link: https://lkml.kernel.org/r/20250918233308.293861-1-phillip@squashfs.org.uk Fixes: 122601408d20 ("Squashfs: export operations") Signed-off-by: Phillip Lougher <phillip(a)squashfs.org.uk> Reported-by: syzbot+157bdef5cf596ad0da2c(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68cc2431.050a0220.139b6.0001.GAE@google.com/ Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/squashfs/inode.c | 7 +++++++ fs/squashfs/squashfs_fs_i.h | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) --- a/fs/squashfs/inode.c~squashfs-fix-uninit-value-in-squashfs_get_parent +++ a/fs/squashfs/inode.c @@ -169,6 +169,7 @@ int squashfs_read_inode(struct inode *in squashfs_i(inode)->start = le32_to_cpu(sqsh_ino->start_block); squashfs_i(inode)->block_list_start = block; squashfs_i(inode)->offset = offset; + squashfs_i(inode)->parent = 0; inode->i_data.a_ops = &squashfs_aops; TRACE("File inode %x:%x, start_block %llx, block_list_start " @@ -216,6 +217,7 @@ int squashfs_read_inode(struct inode *in squashfs_i(inode)->start = le64_to_cpu(sqsh_ino->start_block); squashfs_i(inode)->block_list_start = block; squashfs_i(inode)->offset = offset; + squashfs_i(inode)->parent = 0; inode->i_data.a_ops = &squashfs_aops; TRACE("File inode %x:%x, start_block %llx, block_list_start " @@ -296,6 +298,7 @@ int squashfs_read_inode(struct inode *in inode->i_mode |= S_IFLNK; squashfs_i(inode)->start = block; squashfs_i(inode)->offset = offset; + squashfs_i(inode)->parent = 0; if (type == SQUASHFS_LSYMLINK_TYPE) { __le32 xattr; @@ -333,6 +336,7 @@ int squashfs_read_inode(struct inode *in set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); rdev = le32_to_cpu(sqsh_ino->rdev); init_special_inode(inode, inode->i_mode, new_decode_dev(rdev)); + squashfs_i(inode)->parent = 0; TRACE("Device inode %x:%x, rdev %x\n", SQUASHFS_INODE_BLK(ino), offset, rdev); @@ -357,6 +361,7 @@ int squashfs_read_inode(struct inode *in set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); rdev = le32_to_cpu(sqsh_ino->rdev); init_special_inode(inode, inode->i_mode, new_decode_dev(rdev)); + squashfs_i(inode)->parent = 0; TRACE("Device inode %x:%x, rdev %x\n", SQUASHFS_INODE_BLK(ino), offset, rdev); @@ -377,6 +382,7 @@ int squashfs_read_inode(struct inode *in inode->i_mode |= S_IFSOCK; set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); init_special_inode(inode, inode->i_mode, 0); + squashfs_i(inode)->parent = 0; break; } case SQUASHFS_LFIFO_TYPE: @@ -396,6 +402,7 @@ int squashfs_read_inode(struct inode *in inode->i_op = &squashfs_inode_ops; set_nlink(inode, le32_to_cpu(sqsh_ino->nlink)); init_special_inode(inode, inode->i_mode, 0); + squashfs_i(inode)->parent = 0; break; } default: --- a/fs/squashfs/squashfs_fs_i.h~squashfs-fix-uninit-value-in-squashfs_get_parent +++ a/fs/squashfs/squashfs_fs_i.h @@ -16,6 +16,7 @@ struct squashfs_inode_info { u64 xattr; unsigned int xattr_size; int xattr_count; + int parent; union { struct { u64 fragment_block; @@ -27,7 +28,6 @@ struct squashfs_inode_info { u64 dir_idx_start; int dir_idx_offset; int dir_idx_cnt; - int parent; }; }; struct inode vfs_inode; _ Patches currently in -mm which might be from phillip(a)squashfs.org.uk are

1 month

1
0
0 0

[merged mm-nonmm-stable] kho-only-fill-kimage-if-kho-is-finalized.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: kho: only fill kimage if KHO is finalized has been removed from the -mm tree. Its filename was kho-only-fill-kimage-if-kho-is-finalized.patch This patch was dropped because it was merged into the mm-nonmm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Pratyush Yadav <pratyush(a)kernel.org> Subject: kho: only fill kimage if KHO is finalized Date: Thu, 18 Sep 2025 19:06:15 +0200 kho_fill_kimage() only checks for KHO being enabled before filling in the FDT to the image. KHO being enabled does not mean that the kernel has data to hand over. That happens when KHO is finalized. When a kexec is done with KHO enabled but not finalized, the FDT page is allocated but not initialized. FDT initialization happens after finalize. This means the KHO segment is filled in but the FDT contains garbage data. This leads to the below error messages in the next kernel: [ 0.000000] KHO: setup: handover FDT (0x10116b000) is invalid: -9 [ 0.000000] KHO: disabling KHO revival: -22 There is no problem in practice, and the next kernel boots and works fine. But this still leads to misleading error messages and garbage being handed over. Only fill in KHO segment when KHO is finalized. When KHO is not enabled, the debugfs interface is not created and there is no way to finalize it anyway. So the check for kho_enable is not needed, and kho_out.finalize alone is enough. Link: https://lkml.kernel.org/r/20250918170617.91413-1-pratyush@kernel.org Fixes: 3bdecc3c93f9 ("kexec: add KHO support to kexec file loads") Signed-off-by: Pratyush Yadav <pratyush(a)kernel.org> Reviewed-by: Mike Rapoport (Microsoft) <rppt(a)kernel.org> Cc: Alexander Graf <graf(a)amazon.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Changyuan Lyu <changyuanl(a)google.com> Cc: Jason Gunthorpe <jgg(a)nvidia.com> Cc: Pasha Tatashin <pasha.tatashin(a)soleen.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/kexec_handover.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/kexec_handover.c~kho-only-fill-kimage-if-kho-is-finalized +++ a/kernel/kexec_handover.c @@ -1253,7 +1253,7 @@ int kho_fill_kimage(struct kimage *image int err = 0; struct kexec_buf scratch; - if (!kho_enable) + if (!kho_out.finalized) return 0; image->kho.fdt = page_to_phys(kho_out.ser.fdt); _ Patches currently in -mm which might be from pratyush(a)kernel.org are kho-add-support-for-preserving-vmalloc-allocations-fix.patch

1 month

1
0
0 0

Re: Watermark (917) 267-9470

by Jim Solesky

Good Sunday morning, We hope 2025 has been strong heading into Fall. We continue to look forward to opportunities in structuring funding approval to offer you this year. With hopes of inflation rates continuing to come down, combining with a growing market, Watermark's rates have been and will be as competitive as ever for: * Credit Lines - Working Capital * All Property * All Equipment * Equity Raises - Buyouts We are available to review your fundraising needs around the world on behalf of you and any clients that you may have ready for us. Thank you! Jim Solesky, Managing Partner Office: (917) 267-9470 1 Bryant Park | Bank of America Tower New York, NY, United States 10036 [image5]

1 month

1
0
0 0

D rings , O rings ,clasps ,clips , Plastic hardware ,fastening,rivets , grommets,eyelets,buckles,screws , harnesses ,wires ,bolts ,nuts ,clips ,bits ,spurs ,screws,anchors,stainless

by qualityproduct＠vip.163.com

Dear Sir : I hope you’re doing well! My name is Su, and I represent METAL PRODUCTS, a leading manufacturer of premium metal hardware. We specialize in a wide range of products, including: D rings , O rings ,clasps ,clips , Plastic hardware ,fastening,rivets , grommets,eyelets,buckles,screws , harnesses ,wires ,bolts ,nuts ,clips ,bits ,spurs ,screws,anchors,stainless steel hardware , zamak harnesses,aluminium hardware，brass hardware,steel harnesses ,iron metal hardware,metal & Harnesses,belt and buckles,straps ,leather Harnesses,tags ,belts,straps ,clips ,rings bars ,hooks , safety buckles,brass buckles, brass rings ,belts,buckles ,Split Ring ,straps ,sliders,snaps ,Bars Rings, Fasteners, magnent buttons,craft hardware ,bindings ,knobs,steps ,straps , bits ,eyelets ,tools , metal gear , metal hardware , metal products, metal Components,S hooks ,bars ,snaps ,webbings , buckles, HOOK,brass buckles, clips , hooks ,straps , accessories ,steel wires, wire rings , wire buckles ,brass gears ,brass products ,iron metal hardware ,Fasteners,safety buckles,brass buckles, brass rings ,belts,buckles ,Ring ,Squares ,straps ,sliders,Bars Rings, Buckles, Cord locks, Hooks & Rings,Tabs, Locks and Slides,magnent buttons,carabiners,trigger ,buttons ,snaps ,fasteners, webbings , webbing buckles, buttons, as required for our global clients .Hook Loop ，textile accessories,safety buckles,sliders,snaps ,leather hardware ,bag hardware ,shoe hardware ,cord hardware ,hockey hardware,Rings ,chains,suspenders,custom designs and more ! We are manufactory, we are the source, our price is very competitive ,you will get the best price , We have profuse designs with series quality grade, and expressly. Our factory always produce customer designs and drawing , if you have any products looking please let me know we could surely make for you Sincerely hope could work with you ! Best regards Su

1 month

1
0
0 0

[for-linus][PATCH 3/3] tracing: fgraph: Protect return handler from recursion loop

by Steven Rostedt

From: "Masami Hiramatsu (Google)" <mhiramat(a)kernel.org> function_graph_enter_regs() prevents itself from recursion by ftrace_test_recursion_trylock(), but __ftrace_return_to_handler(), which is called at the exit, does not prevent such recursion. Therefore, while it can prevent recursive calls from fgraph_ops::entryfunc(), it is not able to prevent recursive calls to fgraph from fgraph_ops::retfunc(), resulting in a recursive loop. This can lead an unexpected recursion bug reported by Menglong. is_endbr() is called in __ftrace_return_to_handler -> fprobe_return -> kprobe_multi_link_exit_handler -> is_endbr. To fix this issue, acquire ftrace_test_recursion_trylock() in the __ftrace_return_to_handler() after unwind the shadow stack to mark this section must prevent recursive call of fgraph inside user-defined fgraph_ops::retfunc(). This is essentially a fix to commit 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer"), because before that fgraph was only used from the function graph tracer. Fprobe allowed user to run any callbacks from fgraph after that commit. Reported-by: Menglong Dong <menglong8.dong(a)gmail.com> Closes: https://lore.kernel.org/all/20250918120939.1706585-1-dongml2@chinatelecom.c… Fixes: 4346ba160409 ("fprobe: Rewrite fprobe on function-graph tracer") Cc: stable(a)vger.kernel.org Cc: Peter Zijlstra <peterz(a)infradead.org> Link: https://lore.kernel.org/175852292275.307379.9040117316112640553.stgit@devno… Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Acked-by: Jiri Olsa <jolsa(a)kernel.org> Tested-by: Menglong Dong <menglong8.dong(a)gmail.com> Acked-by: Menglong Dong <menglong8.dong(a)gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/fgraph.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c index 1e3b32b1e82c..484ad7a18463 100644 --- a/kernel/trace/fgraph.c +++ b/kernel/trace/fgraph.c @@ -815,6 +815,7 @@ __ftrace_return_to_handler(struct ftrace_regs *fregs, unsigned long frame_pointe unsigned long bitmap; unsigned long ret; int offset; + int bit; int i; ret_stack = ftrace_pop_return_trace(&trace, &ret, frame_pointer, &offset); @@ -829,6 +830,15 @@ __ftrace_return_to_handler(struct ftrace_regs *fregs, unsigned long frame_pointe if (fregs) ftrace_regs_set_instruction_pointer(fregs, ret); + bit = ftrace_test_recursion_trylock(trace.func, ret); + /* + * This can fail because ftrace_test_recursion_trylock() allows one nest + * call. If we are already in a nested call, then we don't probe this and + * just return the original return address. + */ + if (unlikely(bit < 0)) + goto out; + #ifdef CONFIG_FUNCTION_GRAPH_RETVAL trace.retval = ftrace_regs_get_return_value(fregs); #endif @@ -852,6 +862,8 @@ __ftrace_return_to_handler(struct ftrace_regs *fregs, unsigned long frame_pointe } } + ftrace_test_recursion_unlock(bit); +out: /* * The ftrace_graph_return() may still access the current * ret_stack structure, we need to make sure the update of -- 2.50.1

1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror