July 2025 - Linux-stable-mirror

Direct Access to ISE 2025 Leads-20% OFF!

by Mary Jennifer

Hi, Imagine having direct access to 1,605 top exhibitors and 86,571 attendees at Integrated Systems Europe (ISE) 2025. We have the latest comprehensive list with last-minute additions, helping you connect with decision-makers, industry leaders, and potential partners. Available Data Fields: Individual Email Address, Phone Number, Contact Name, Job Title, Company Name, Website, Physical Address, and more. Act fast — respond by July 20th to claim your 20% discount. Interested? Simply reply with “Send me pricing” and I’ll get all the details over to you. Best regards, Mary Jannifer Sr. Demand Generation Not interested? Reply “Unfollow” to opt out.

2 months, 3 weeks

1
0
0 0

[PATCH v4] char: xillybus: Fix error handling in xillybus_init_chrdev()

by Ma Ke

Use cdev_del() instead of direct kobject_put() when cdev_add() fails. This aligns with standard kernel practice and maintains consistency within the driver's own error paths. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 8cb5d216ab33 ("char: xillybus: Move class-related functions to new xillybus_class.c") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- Changes in v4: - Apologize, due to the long time that has passed since the last v2 version, I was negligent when submitting v3. I have now corrected it; Changes in v3: - modified the patch description, centralized cdev cleanup through standard API and maintained symmetry with driver's existing error handling; Changes in v2: - modified the patch as suggestions to avoid UAF. --- drivers/char/xillybus/xillybus_class.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/char/xillybus/xillybus_class.c b/drivers/char/xillybus/xillybus_class.c index c92a628e389e..493bbed918c2 100644 --- a/drivers/char/xillybus/xillybus_class.c +++ b/drivers/char/xillybus/xillybus_class.c @@ -103,8 +103,7 @@ int xillybus_init_chrdev(struct device *dev, unit->num_nodes); if (rc) { dev_err(dev, "Failed to add cdev.\n"); - /* kobject_put() is normally done by cdev_del() */ - kobject_put(&unit->cdev->kobj); + cdev_del(unit->cdev); goto unregister_chrdev; } -- 2.25.1

2 months, 3 weeks

3
2
0 0

[merged mm-hotfixes-stable] kasan-use-vmalloc_dump_obj-for-vmalloc-error-reports.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: kasan: use vmalloc_dump_obj() for vmalloc error reports has been removed from the -mm tree. Its filename was kasan-use-vmalloc_dump_obj-for-vmalloc-error-reports.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Marco Elver <elver(a)google.com> Subject: kasan: use vmalloc_dump_obj() for vmalloc error reports Date: Wed, 16 Jul 2025 17:23:28 +0200 Since 6ee9b3d84775 ("kasan: remove kasan_find_vm_area() to prevent possible deadlock"), more detailed info about the vmalloc mapping and the origin was dropped due to potential deadlocks. While fixing the deadlock is necessary, that patch was too quick in killing an otherwise useful feature, and did no due-diligence in understanding if an alternative option is available. Restore printing more helpful vmalloc allocation info in KASAN reports with the help of vmalloc_dump_obj(). Example report: | BUG: KASAN: vmalloc-out-of-bounds in vmalloc_oob+0x4c9/0x610 | Read of size 1 at addr ffffc900002fd7f3 by task kunit_try_catch/493 | | CPU: [...] | Call Trace: | <TASK> | dump_stack_lvl+0xa8/0xf0 | print_report+0x17e/0x810 | kasan_report+0x155/0x190 | vmalloc_oob+0x4c9/0x610 | [...] | | The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900002fd000 allocated at vmalloc_oob+0x36/0x610 | The buggy address belongs to the physical page: | page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x126364 | flags: 0x200000000000000(node=0|zone=2) | raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 | raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 | page dumped because: kasan: bad access detected | | [..] Link: https://lkml.kernel.org/r/20250716152448.3877201-1-elver@google.com Fixes: 6ee9b3d84775 ("kasan: remove kasan_find_vm_area() to prevent possible deadlock") Signed-off-by: Marco Elver <elver(a)google.com> Suggested-by: Uladzislau Rezki <urezki(a)gmail.com> Acked-by: Uladzislau Rezki (Sony) <urezki(a)gmail.com> Cc: Alexander Potapenko <glider(a)google.com> Cc: Andrey Konovalov <andreyknvl(a)gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a(a)gmail.com> Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> Cc: Yeoreum Yun <yeoreum.yun(a)arm.com> Cc: Yunseong Kim <ysk(a)kzalloc.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/kasan/report.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/mm/kasan/report.c~kasan-use-vmalloc_dump_obj-for-vmalloc-error-reports +++ a/mm/kasan/report.c @@ -399,7 +399,9 @@ static void print_address_description(vo } if (is_vmalloc_addr(addr)) { - pr_err("The buggy address %px belongs to a vmalloc virtual mapping\n", addr); + pr_err("The buggy address belongs to a"); + if (!vmalloc_dump_obj(addr)) + pr_cont(" vmalloc virtual mapping\n"); page = vmalloc_to_page(addr); } _ Patches currently in -mm which might be from elver(a)google.com are

2 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-ksm-fix-wsometimes-uninitialized-from-clang-21-in-advisor_mode_show.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/ksm: fix -Wsometimes-uninitialized from clang-21 in advisor_mode_show() has been removed from the -mm tree. Its filename was mm-ksm-fix-wsometimes-uninitialized-from-clang-21-in-advisor_mode_show.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Nathan Chancellor <nathan(a)kernel.org> Subject: mm/ksm: fix -Wsometimes-uninitialized from clang-21 in advisor_mode_show() Date: Tue, 15 Jul 2025 12:56:16 -0700 After a recent change in clang to expose uninitialized warnings from const variables [1], there is a false positive warning from the if statement in advisor_mode_show(). mm/ksm.c:3687:11: error: variable 'output' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] 3687 | else if (ksm_advisor == KSM_ADVISOR_SCAN_TIME) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mm/ksm.c:3690:33: note: uninitialized use occurs here 3690 | return sysfs_emit(buf, "%s\n", output); | ^~~~~~ Rewrite the if statement to implicitly make KSM_ADVISOR_NONE the else branch so that it is obvious to the compiler that ksm_advisor can only be KSM_ADVISOR_NONE or KSM_ADVISOR_SCAN_TIME due to the assignments in advisor_mode_store(). Link: https://lkml.kernel.org/r/20250715-ksm-fix-clang-21-uninit-warning-v1-1-f44… Fixes: 66790e9a735b ("mm/ksm: add sysfs knobs for advisor") Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> Closes: https://github.com/ClangBuiltLinux/linux/issues/2100 Link: https://github.com/llvm/llvm-project/commit/2464313eef01c5b1edf0eccf57a32cd… [1] Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Chengming Zhou <chengming.zhou(a)linux.dev> Cc: Stefan Roesch <shr(a)devkernel.io> Cc: xu xin <xu.xin16(a)zte.com.cn> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/ksm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/mm/ksm.c~mm-ksm-fix-wsometimes-uninitialized-from-clang-21-in-advisor_mode_show +++ a/mm/ksm.c @@ -3669,10 +3669,10 @@ static ssize_t advisor_mode_show(struct { const char *output; - if (ksm_advisor == KSM_ADVISOR_NONE) - output = "[none] scan-time"; - else if (ksm_advisor == KSM_ADVISOR_SCAN_TIME) + if (ksm_advisor == KSM_ADVISOR_SCAN_TIME) output = "none [scan-time]"; + else + output = "[none] scan-time"; return sysfs_emit(buf, "%s\n", output); } _ Patches currently in -mm which might be from nathan(a)kernel.org are

2 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] nilfs2-reject-invalid-file-types-when-reading-inodes.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: nilfs2: reject invalid file types when reading inodes has been removed from the -mm tree. Its filename was nilfs2-reject-invalid-file-types-when-reading-inodes.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Subject: nilfs2: reject invalid file types when reading inodes Date: Thu, 10 Jul 2025 22:49:08 +0900 To prevent inodes with invalid file types from tripping through the vfs and causing malfunctions or assertion failures, add a missing sanity check when reading an inode from a block device. If the file type is not valid, treat it as a filesystem error. Link: https://lkml.kernel.org/r/20250710134952.29862-1-konishi.ryusuke@gmail.com Fixes: 05fe58fdc10d ("nilfs2: inode operations") Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)gmail.com> Reported-by: syzbot+895c23f6917da440ed0d(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=895c23f6917da440ed0d Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/nilfs2/inode.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/fs/nilfs2/inode.c~nilfs2-reject-invalid-file-types-when-reading-inodes +++ a/fs/nilfs2/inode.c @@ -472,11 +472,18 @@ static int __nilfs_read_inode(struct sup inode->i_op = &nilfs_symlink_inode_operations; inode_nohighmem(inode); inode->i_mapping->a_ops = &nilfs_aops; - } else { + } else if (S_ISCHR(inode->i_mode) || S_ISBLK(inode->i_mode) || + S_ISFIFO(inode->i_mode) || S_ISSOCK(inode->i_mode)) { inode->i_op = &nilfs_special_inode_operations; init_special_inode( inode, inode->i_mode, huge_decode_dev(le64_to_cpu(raw_inode->i_device_code))); + } else { + nilfs_error(sb, + "invalid file type bits in mode 0%o for inode %lu", + inode->i_mode, ino); + err = -EIO; + goto failed_unmap; } nilfs_ifile_unmap_inode(raw_inode); brelse(bh); _ Patches currently in -mm which might be from konishi.ryusuke(a)gmail.com are

2 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] selftests-mm-fix-split_huge_page_test-for-folio_split-tests.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: selftests/mm: fix split_huge_page_test for folio_split() tests has been removed from the -mm tree. Its filename was selftests-mm-fix-split_huge_page_test-for-folio_split-tests.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Zi Yan <ziy(a)nvidia.com> Subject: selftests/mm: fix split_huge_page_test for folio_split() tests Date: Tue, 8 Jul 2025 21:27:59 -0400 PID_FMT does not have an offset field, so folio_split() tests are not performed. Add PID_FMT_OFFSET with an offset field and use it to perform folio_split() tests. Link: https://lkml.kernel.org/r/20250709012800.3225727-1-ziy@nvidia.com Fixes: 80a5c494c89f ("selftests/mm: add tests for folio_split(), buddy allocator like split") Signed-off-by: Zi Yan <ziy(a)nvidia.com> Tested-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Reviewed-by: Donet Tom <donettom(a)linux.ibm.com> Tested-by : Donet Tom <donettom(a)linux.ibm.com> Cc: Barry Song <baohua(a)kernel.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Dev Jain <dev.jain(a)arm.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Mariano Pache <npache(a)redhat.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/split_huge_page_test.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/tools/testing/selftests/mm/split_huge_page_test.c~selftests-mm-fix-split_huge_page_test-for-folio_split-tests +++ a/tools/testing/selftests/mm/split_huge_page_test.c @@ -31,6 +31,7 @@ uint64_t pmd_pagesize; #define INPUT_MAX 80 #define PID_FMT "%d,0x%lx,0x%lx,%d" +#define PID_FMT_OFFSET "%d,0x%lx,0x%lx,%d,%d" #define PATH_FMT "%s,0x%lx,0x%lx,%d" #define PFN_MASK ((1UL<<55)-1) @@ -483,7 +484,7 @@ void split_thp_in_pagecache_to_order_at( write_debugfs(PID_FMT, getpid(), (uint64_t)addr, (uint64_t)addr + fd_size, order); else - write_debugfs(PID_FMT, getpid(), (uint64_t)addr, + write_debugfs(PID_FMT_OFFSET, getpid(), (uint64_t)addr, (uint64_t)addr + fd_size, order, offset); for (i = 0; i < fd_size; i++) _ Patches currently in -mm which might be from ziy(a)nvidia.com are mm-huge_memory-move-unrelated-code-out-of-__split_unmapped_folio.patch mm-huge_memory-remove-after_split-label-in-__split_unmapped_folio.patch mm-huge_memory-deduplicate-code-in-__folio_split.patch mm-huge_memory-convert-vm_bug-to-vm_warn-in-__folio_split.patch mm-huge_memory-get-frozen-folio-refcount-with-folio_expected_ref_count.patch mm-huge_memory-refactor-after-split-page-cache-code.patch

2 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-zsmalloc-do-not-pass-__gfp_movable-if-config_compaction=n.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/zsmalloc: do not pass __GFP_MOVABLE if CONFIG_COMPACTION=n has been removed from the -mm tree. Its filename was mm-zsmalloc-do-not-pass-__gfp_movable-if-config_compaction=n.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Harry Yoo <harry.yoo(a)oracle.com> Subject: mm/zsmalloc: do not pass __GFP_MOVABLE if CONFIG_COMPACTION=n Date: Fri, 4 Jul 2025 19:30:53 +0900 Commit 48b4800a1c6a ("zsmalloc: page migration support") added support for migrating zsmalloc pages using the movable_operations migration framework. However, the commit did not take into account that zsmalloc supports migration only when CONFIG_COMPACTION is enabled. Tracing shows that zsmalloc was still passing the __GFP_MOVABLE flag even when compaction is not supported. This can result in unmovable pages being allocated from movable page blocks (even without stealing page blocks), ZONE_MOVABLE and CMA area. Possible user visible effects: - Some ZONE_MOVABLE memory can be not actually movable - CMA allocation can fail because of this - Increased memory fragmentation due to ignoring the page mobility grouping feature I'm not really sure who uses kernels without compaction support, though :( To fix this, clear the __GFP_MOVABLE flag when !IS_ENABLED(CONFIG_COMPACTION). Link: https://lkml.kernel.org/r/20250704103053.6913-1-harry.yoo@oracle.com Fixes: 48b4800a1c6a ("zsmalloc: page migration support") Signed-off-by: Harry Yoo <harry.yoo(a)oracle.com> Acked-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: Minchan Kim <minchan(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/zsmalloc.c | 3 +++ 1 file changed, 3 insertions(+) --- a/mm/zsmalloc.c~mm-zsmalloc-do-not-pass-__gfp_movable-if-config_compaction=n +++ a/mm/zsmalloc.c @@ -1043,6 +1043,9 @@ static struct zspage *alloc_zspage(struc if (!zspage) return NULL; + if (!IS_ENABLED(CONFIG_COMPACTION)) + gfp &= ~__GFP_MOVABLE; + zspage->magic = ZSPAGE_MAGIC; zspage->pool = pool; zspage->class = class->index; _ Patches currently in -mm which might be from harry.yoo(a)oracle.com are

2 months, 3 weeks

1
0
0 0

[merged mm-hotfixes-stable] mm-vmscan-fix-hwpoisoned-large-folio-handling-in-shrink_folio_list.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list has been removed from the -mm tree. Its filename was mm-vmscan-fix-hwpoisoned-large-folio-handling-in-shrink_folio_list.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Jinjiang Tu <tujinjiang(a)huawei.com> Subject: mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list Date: Fri, 27 Jun 2025 20:57:46 +0800 In shrink_folio_list(), the hwpoisoned folio may be large folio, which can't be handled by unmap_poisoned_folio(). For THP, try_to_unmap_one() must be passed with TTU_SPLIT_HUGE_PMD to split huge PMD first and then retry. Without TTU_SPLIT_HUGE_PMD, we will trigger null-ptr deref of pvmw.pte. Even we passed TTU_SPLIT_HUGE_PMD, we will trigger a WARN_ON_ONCE due to the page isn't in swapcache. Since UCE is rare in real world, and race with reclaimation is more rare, just skipping the hwpoisoned large folio is enough. memory_failure() will handle it if the UCE is triggered again. This happens when memory reclaim for large folio races with memory_failure(), and will lead to kernel panic. The race is as follows: cpu0 cpu1 shrink_folio_list memory_failure TestSetPageHWPoison unmap_poisoned_folio --> trigger BUG_ON due to unmap_poisoned_folio couldn't handle large folio [tujinjiang(a)huawei.com: add comment to unmap_poisoned_folio()] Link: https://lkml.kernel.org/r/69fd4e00-1b13-d5f7-1c82-705c7d977ea4@huawei.com Link: https://lkml.kernel.org/r/20250627125747.3094074-2-tujinjiang@huawei.com Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Fixes: 1b0449544c64 ("mm/vmscan: don't try to reclaim hwpoison folio") Reported-by: syzbot+3b220254df55d8ca8a61(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68412d57.050a0220.2461cf.000e.GAE@google.com/ Acked-by: David Hildenbrand <david(a)redhat.com> Reviewed-by: Miaohe Lin <linmiaohe(a)huawei.com> Acked-by: Zi Yan <ziy(a)nvidia.com> Reviewed-by: Oscar Salvador <osalvador(a)suse.de> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory-failure.c | 4 ++++ mm/vmscan.c | 8 ++++++++ 2 files changed, 12 insertions(+) --- a/mm/memory-failure.c~mm-vmscan-fix-hwpoisoned-large-folio-handling-in-shrink_folio_list +++ a/mm/memory-failure.c @@ -1561,6 +1561,10 @@ static int get_hwpoison_page(struct page return ret; } +/* + * The caller must guarantee the folio isn't large folio, except hugetlb. + * try_to_unmap() can't handle it. + */ int unmap_poisoned_folio(struct folio *folio, unsigned long pfn, bool must_kill) { enum ttu_flags ttu = TTU_IGNORE_MLOCK | TTU_SYNC | TTU_HWPOISON; --- a/mm/vmscan.c~mm-vmscan-fix-hwpoisoned-large-folio-handling-in-shrink_folio_list +++ a/mm/vmscan.c @@ -1138,6 +1138,14 @@ retry: goto keep; if (folio_contain_hwpoisoned_page(folio)) { + /* + * unmap_poisoned_folio() can't handle large + * folio, just skip it. memory_failure() will + * handle it if the UCE is triggered again. + */ + if (folio_test_large(folio)) + goto keep_locked; + unmap_poisoned_folio(folio, folio_pfn(folio), false); folio_unlock(folio); folio_put(folio); _ Patches currently in -mm which might be from tujinjiang(a)huawei.com are mm-memory_hotplug-fix-hwpoisoned-large-folio-handling-in-do_migrate_range.patch

2 months, 3 weeks

1
0
0 0

[PATCH] Fix SMB311 posix special file creation to servers which do not advertise reparse support

by Junhyeok Park

From: Steve French <stfrench(a)microsoft.com> Some servers (including Samba), support the SMB3.1.1 POSIX Extensions (which use reparse points for handling special files) but do not properly advertise file system attribute FILE_SUPPORTS_REPARSE_POINTS. Although we don't check for this attribute flag when querying special file information, we do check it when creating special files which causes them to fail unnecessarily. If we have negotiated SMB3.1.1 POSIX Extensions with the server we can expect the server to support creating special files via reparse points, and even if the server fails the operation due to really forbidding creating special files, then it should be no problem and is more likely to return a more accurate rc in any case (e.g. EACCES instead of EOPNOTSUPP). Allow creating special files as long as the server supports either reparse points or the SMB3.1.1 POSIX Extensions (note that if the "sfu" mount option is specified it uses a different way of storing special files that does not rely on reparse points). Cc: <stable(a)vger.kernel.org> Fixes: 6c06be908ca19 ("cifs: Check if server supports reparse points before using them") Acked-by: Ralph Boehme <slow(a)samba.org> Acked-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> --- fs/smb/client/smb2inode.c | 3 ++- fs/smb/client/smb2ops.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/smb/client/smb2inode.c b/fs/smb/client/smb2inode.c index 2a3e46b8e15a..a11a2a693c51 100644 --- a/fs/smb/client/smb2inode.c +++ b/fs/smb/client/smb2inode.c @@ -1346,7 +1346,8 @@ struct inode *smb2_get_reparse_inode(struct cifs_open_info_data *data, * empty object on the server. */ if (!(le32_to_cpu(tcon->fsAttrInfo.Attributes) & FILE_SUPPORTS_REPARSE_POINTS)) - return ERR_PTR(-EOPNOTSUPP); + if (!tcon->posix_extensions) + return ERR_PTR(-EOPNOTSUPP); oparms = CIFS_OPARMS(cifs_sb, tcon, full_path, SYNCHRONIZE | DELETE | diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c index cb659256d219..938a8a7c5d21 100644 --- a/fs/smb/client/smb2ops.c +++ b/fs/smb/client/smb2ops.c @@ -5260,7 +5260,8 @@ static int smb2_make_node(unsigned int xid, struct inode *inode, if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_UNX_EMUL) { rc = cifs_sfu_make_node(xid, inode, dentry, tcon, full_path, mode, dev); - } else if (le32_to_cpu(tcon->fsAttrInfo.Attributes) & FILE_SUPPORTS_REPARSE_POINTS) { + } else if ((le32_to_cpu(tcon->fsAttrInfo.Attributes) & FILE_SUPPORTS_REPARSE_POINTS) + || (tcon->posix_extensions)) { rc = smb2_mknod_reparse(xid, inode, dentry, tcon, full_path, mode, dev); } -- 2.34.1

2 months, 3 weeks

1
0
0 0

[merged mm-stable] mm-hmm-move-pmd_to_hmm_pfn_flags-to-the-respective-ifdeffery.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/hmm: move pmd_to_hmm_pfn_flags() to the respective #ifdeffery has been removed from the -mm tree. Its filename was mm-hmm-move-pmd_to_hmm_pfn_flags-to-the-respective-ifdeffery.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: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Subject: mm/hmm: move pmd_to_hmm_pfn_flags() to the respective #ifdeffery Date: Thu, 10 Jul 2025 11:23:53 +0300 When pmd_to_hmm_pfn_flags() is unused, it prevents kernel builds with clang, `make W=1` and CONFIG_TRANSPARENT_HUGEPAGE=n: mm/hmm.c:186:29: warning: unused function 'pmd_to_hmm_pfn_flags' [-Wunused-function] Fix this by moving the function to the respective existing ifdeffery for its the only user. See also: 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build") Link: https://lkml.kernel.org/r/20250710082403.664093-1-andriy.shevchenko@linux.i… Fixes: 992de9a8b751 ("mm/hmm: allow to mirror vma of a file on a DAX backed filesystem") Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Reviewed-by: Leon Romanovsky <leonro(a)nvidia.com> Reviewed-by: Alistair Popple <apopple(a)nvidia.com> Cc: Andriy Shevchenko <andriy.shevchenko(a)linux.intel.com> Cc: Bill Wendling <morbo(a)google.com> Cc: Jerome Glisse <jglisse(a)redhat.com> Cc: Justin Stitt <justinstitt(a)google.com> Cc: Nathan Chancellor <nathan(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hmm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/hmm.c~mm-hmm-move-pmd_to_hmm_pfn_flags-to-the-respective-ifdeffery +++ a/mm/hmm.c @@ -183,6 +183,7 @@ static inline unsigned long hmm_pfn_flag return order << HMM_PFN_ORDER_SHIFT; } +#ifdef CONFIG_TRANSPARENT_HUGEPAGE static inline unsigned long pmd_to_hmm_pfn_flags(struct hmm_range *range, pmd_t pmd) { @@ -193,7 +194,6 @@ static inline unsigned long pmd_to_hmm_p hmm_pfn_flags_order(PMD_SHIFT - PAGE_SHIFT); } -#ifdef CONFIG_TRANSPARENT_HUGEPAGE static int hmm_vma_handle_pmd(struct mm_walk *walk, unsigned long addr, unsigned long end, unsigned long hmm_pfns[], pmd_t pmd) _ Patches currently in -mm which might be from andriy.shevchenko(a)linux.intel.com are

2 months, 3 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2025