May 2025 - Linux-stable-mirror

RE: Drive Results for MRO & Air Charter with Targeted Contact Solutions

by Jessica Garcia

Hi , Circling back to see if you had any questions about my earlier email. Feel free to share your target industries and job titles, and I'll provide the relevant pricing and volume information. Regards, Jessica Marketing Manager Campaign Data Leads., Please respond with an Remove if you don't wish to receive further emails. -----Original Message----- From: Jessica Garcia Subject: Drive Results for MRO & Air Charter with Targeted Contact Solutions Hi , I'm offering a resource that connects aviation outreach with data-backed direction. We provide a current and verified list of contacts, tailored specifically for your industry. (i) High-Net-Worth Individuals (HNWI) seeking seamless luxury travel and private charters (ii) MRO Professionals focused on enhancing maintenance and procurement strategies (iii) Executive Assistants managing the travel needs of high-ranking executives For businesses offering aviation products, maintenance services, or charter flights, these contacts are ideal for your campaign. Please let me know if you'd like to explore the lead counts and their pricing structure. Regards, Jessica Marketing Manager Campaign Data Leads., Please respond with an Remove if you don't wish to receive further emails.

5 months, 2 weeks

1
0
0 0

[to-be-updated] mm-hugetlb-fix-a-deadlock-with-pagecache_folio-and-hugetlb_fault_mutex_table.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/hugetlb: fix a deadlock with pagecache_folio and hugetlb_fault_mutex_table has been removed from the -mm tree. Its filename was mm-hugetlb-fix-a-deadlock-with-pagecache_folio-and-hugetlb_fault_mutex_table.patch This patch was dropped because an updated version will be issued ------------------------------------------------------ From: Gavin Guo <gavinguo(a)igalia.com> Subject: mm/hugetlb: fix a deadlock with pagecache_folio and hugetlb_fault_mutex_table Date: Tue, 13 May 2025 17:34:48 +0800 Fix a deadlock which can be triggered by an internal syzkaller [1] reproducer and captured by bpftrace script [2] and its log [3] in this scenario: Process 1 Process 2 --- --- hugetlb_fault mutex_lock(B) // take B filemap_lock_hugetlb_folio filemap_lock_folio __filemap_get_folio folio_lock(A) // take A hugetlb_wp mutex_unlock(B) // release B ... hugetlb_fault ... mutex_lock(B) // take B filemap_lock_hugetlb_folio filemap_lock_folio __filemap_get_folio folio_lock(A) // blocked unmap_ref_private ... mutex_lock(B) // retake and blocked This is a ABBA deadlock involving two locks: - Lock A: pagecache_folio lock - Lock B: hugetlb_fault_mutex_table lock The deadlock occurs between two processes as follows: 1. The first process (let's call it Process 1) is handling a copy-on-write (COW) operation on a hugepage via hugetlb_wp. Due to insufficient reserved hugetlb pages, Process 1, owner of the reserved hugetlb page, attempts to unmap a hugepage owned by another process (non-owner) to satisfy the reservation. Before unmapping, Process 1 acquires lock B (hugetlb_fault_mutex_table lock) and then lock A (pagecache_folio lock). To proceed with the unmap, it releases Lock B but retains Lock A. After the unmap, Process 1 tries to reacquire Lock B. However, at this point, Lock B has already been acquired by another process. 2. The second process (Process 2) enters the hugetlb_fault handler during the unmap operation. It successfully acquires Lock B (hugetlb_fault_mutex_table lock) that was just released by Process 1, but then attempts to acquire Lock A (pagecache_folio lock), which is still held by Process 1. As a result, Process 1 (holding Lock A) is blocked waiting for Lock B (held by Process 2), while Process 2 (holding Lock B) is blocked waiting for Lock A (held by Process 1), constructing a ABBA deadlock scenario. The solution here is to unlock the pagecache_folio and provide the pagecache_folio_unlocked variable to the caller to have the visibility over the pagecache_folio status for subsequent handling. The error message: INFO: task repro_20250402_:13229 blocked for more than 64 seconds. Not tainted 6.15.0-rc3+ #24 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:repro_20250402_ state:D stack:25856 pid:13229 tgid:13228 ppid:3513 task_flags:0x400040 flags:0x00004006 Call Trace: <TASK> __schedule+0x1755/0x4f50 schedule+0x158/0x330 schedule_preempt_disabled+0x15/0x30 __mutex_lock+0x75f/0xeb0 hugetlb_wp+0xf88/0x3440 hugetlb_fault+0x14c8/0x2c30 trace_clock_x86_tsc+0x20/0x20 do_user_addr_fault+0x61d/0x1490 exc_page_fault+0x64/0x100 asm_exc_page_fault+0x26/0x30 RIP: 0010:__put_user_4+0xd/0x20 copy_process+0x1f4a/0x3d60 kernel_clone+0x210/0x8f0 __x64_sys_clone+0x18d/0x1f0 do_syscall_64+0x6a/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x41b26d </TASK> INFO: task repro_20250402_:13229 is blocked on a mutex likely owned by task repro_20250402_:13250. task:repro_20250402_ state:D stack:28288 pid:13250 tgid:13228 ppid:3513 task_flags:0x400040 flags:0x00000006 Call Trace: <TASK> __schedule+0x1755/0x4f50 schedule+0x158/0x330 io_schedule+0x92/0x110 folio_wait_bit_common+0x69a/0xba0 __filemap_get_folio+0x154/0xb70 hugetlb_fault+0xa50/0x2c30 trace_clock_x86_tsc+0x20/0x20 do_user_addr_fault+0xace/0x1490 exc_page_fault+0x64/0x100 asm_exc_page_fault+0x26/0x30 RIP: 0033:0x402619 </TASK> INFO: task repro_20250402_:13250 blocked for more than 65 seconds. Not tainted 6.15.0-rc3+ #24 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:repro_20250402_ state:D stack:28288 pid:13250 tgid:13228 ppid:3513 task_flags:0x400040 flags:0x00000006 Call Trace: <TASK> __schedule+0x1755/0x4f50 schedule+0x158/0x330 io_schedule+0x92/0x110 folio_wait_bit_common+0x69a/0xba0 __filemap_get_folio+0x154/0xb70 hugetlb_fault+0xa50/0x2c30 trace_clock_x86_tsc+0x20/0x20 do_user_addr_fault+0xace/0x1490 exc_page_fault+0x64/0x100 asm_exc_page_fault+0x26/0x30 RIP: 0033:0x402619 </TASK> Showing all locks held in the system: 1 lock held by khungtaskd/35: #0: ffffffff879a7440 (rcu_read_lock){....}-{1:3}, at: debug_show_all_locks+0x30/0x180 2 locks held by repro_20250402_/13229: #0: ffff888017d801e0 (&mm->mmap_lock){++++}-{4:4}, at: lock_mm_and_find_vma+0x37/0x300 #1: ffff888000fec848 (&hugetlb_fault_mutex_table[i]){+.+.}-{4:4}, at: hugetlb_wp+0xf88/0x3440 3 locks held by repro_20250402_/13250: #0: ffff8880177f3d08 (vm_lock){++++}-{0:0}, at: do_user_addr_fault+0x41b/0x1490 #1: ffff888000fec848 (&hugetlb_fault_mutex_table[i]){+.+.}-{4:4}, at: hugetlb_fault+0x3b8/0x2c30 #2: ffff8880129500e8 (&resv_map->rw_sema){++++}-{4:4}, at: hugetlb_fault+0x494/0x2c30 Link: https://drive.google.com/file/d/1DVRnIW-vSayU5J1re9Ct_br3jJQU6Vpb/view?usp=… [1] Link: https://github.com/bboymimi/bpftracer/blob/master/scripts/hugetlb_lock_debu… [2] Link: https://drive.google.com/file/d/1bWq2-8o-BJAuhoHWX7zAhI6ggfhVzQUI/view?usp=… [3] Link: https://lkml.kernel.org/r/20250513093448.592150-1-gavinguo@igalia.com Fixes: 40549ba8f8e0 ("hugetlb: use new vma_lock for pmd sharing synchronization") Signed-off-by: Gavin Guo <gavinguo(a)igalia.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Florent Revest <revest(a)google.com> Cc: Gavin Shan <gshan(a)redhat.com> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Byungchul Park <byungchul(a)sk.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 33 ++++++++++++++++++++++++++++----- 1 file changed, 28 insertions(+), 5 deletions(-) --- a/mm/hugetlb.c~mm-hugetlb-fix-a-deadlock-with-pagecache_folio-and-hugetlb_fault_mutex_table +++ a/mm/hugetlb.c @@ -6131,7 +6131,8 @@ static void unmap_ref_private(struct mm_ * Keep the pte_same checks anyway to make transition from the mutex easier. */ static vm_fault_t hugetlb_wp(struct folio *pagecache_folio, - struct vm_fault *vmf) + struct vm_fault *vmf, + bool *pagecache_folio_unlocked) { struct vm_area_struct *vma = vmf->vma; struct mm_struct *mm = vma->vm_mm; @@ -6229,6 +6230,22 @@ retry_avoidcopy: folio_put(old_folio); /* + * The pagecache_folio needs to be unlocked to avoid + * deadlock and we won't re-lock it in hugetlb_wp(). The + * pagecache_folio could be truncated after being + * unlocked. So its state should not be relied + * subsequently. + * + * Setting *pagecache_folio_unlocked to true allows the + * caller to handle any necessary logic related to the + * folio's unlocked state. + */ + if (pagecache_folio) { + folio_unlock(pagecache_folio); + if (pagecache_folio_unlocked) + *pagecache_folio_unlocked = true; + } + /* * Drop hugetlb_fault_mutex and vma_lock before * unmapping. unmapping needs to hold vma_lock * in write mode. Dropping vma_lock in read mode @@ -6581,7 +6598,7 @@ static vm_fault_t hugetlb_no_page(struct hugetlb_count_add(pages_per_huge_page(h), mm); if ((vmf->flags & FAULT_FLAG_WRITE) && !(vma->vm_flags & VM_SHARED)) { /* Optimization, do the COW without a second fault */ - ret = hugetlb_wp(folio, vmf); + ret = hugetlb_wp(folio, vmf, NULL); } spin_unlock(vmf->ptl); @@ -6653,6 +6670,7 @@ vm_fault_t hugetlb_fault(struct mm_struc struct hstate *h = hstate_vma(vma); struct address_space *mapping; int need_wait_lock = 0; + bool pagecache_folio_unlocked = false; struct vm_fault vmf = { .vma = vma, .address = address & huge_page_mask(h), @@ -6807,7 +6825,8 @@ vm_fault_t hugetlb_fault(struct mm_struc if (flags & (FAULT_FLAG_WRITE|FAULT_FLAG_UNSHARE)) { if (!huge_pte_write(vmf.orig_pte)) { - ret = hugetlb_wp(pagecache_folio, &vmf); + ret = hugetlb_wp(pagecache_folio, &vmf, + &pagecache_folio_unlocked); goto out_put_page; } else if (likely(flags & FAULT_FLAG_WRITE)) { vmf.orig_pte = huge_pte_mkdirty(vmf.orig_pte); @@ -6824,10 +6843,14 @@ out_put_page: out_ptl: spin_unlock(vmf.ptl); - if (pagecache_folio) { + /* + * If the pagecache_folio is unlocked in hugetlb_wp(), we skip + * folio_unlock() here. + */ + if (pagecache_folio && !pagecache_folio_unlocked) folio_unlock(pagecache_folio); + if (pagecache_folio) folio_put(pagecache_folio); - } out_mutex: hugetlb_vma_unlock_read(vma); _ Patches currently in -mm which might be from gavinguo(a)igalia.com are

5 months, 2 weeks

1
0
0 0

[PATCH 1/1] alloc_tag: handle module codetag load errors as module load failures

by Suren Baghdasaryan

Failures inside codetag_load_module() are currently ignored. As a result an error there would not cause a module load failure and freeing of the associated resources. Correct this behavior by propagating the error code to the caller and handling possible errors. With this change, error to allocate percpu counters, which happens at this stage, will not be ignored and will cause a module load failure and freeing of resources. With this change we also do not need to disable memory allocation profiling when this error happens, instead we fail to load the module. Fixes: 10075262888b ("alloc_tag: allocate percpu counters for module tags dynamically") Reported-by: Casey Chen <cachen(a)purestorage.com> Closes: https://lore.kernel.org/all/20250520231620.15259-1-cachen@purestorage.com/ Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Cc: stable(a)vger.kernel.org --- include/linux/codetag.h | 8 ++++---- kernel/module/main.c | 5 +++-- lib/alloc_tag.c | 12 +++++++----- lib/codetag.c | 34 +++++++++++++++++++++++++--------- 4 files changed, 39 insertions(+), 20 deletions(-) diff --git a/include/linux/codetag.h b/include/linux/codetag.h index 0ee4c21c6dbc..5f2b9a1f722c 100644 --- a/include/linux/codetag.h +++ b/include/linux/codetag.h @@ -36,8 +36,8 @@ union codetag_ref { struct codetag_type_desc { const char *section; size_t tag_size; - void (*module_load)(struct module *mod, - struct codetag *start, struct codetag *end); + int (*module_load)(struct module *mod, + struct codetag *start, struct codetag *end); void (*module_unload)(struct module *mod, struct codetag *start, struct codetag *end); #ifdef CONFIG_MODULES @@ -89,7 +89,7 @@ void *codetag_alloc_module_section(struct module *mod, const char *name, unsigned long align); void codetag_free_module_sections(struct module *mod); void codetag_module_replaced(struct module *mod, struct module *new_mod); -void codetag_load_module(struct module *mod); +int codetag_load_module(struct module *mod); void codetag_unload_module(struct module *mod); #else /* defined(CONFIG_CODE_TAGGING) && defined(CONFIG_MODULES) */ @@ -103,7 +103,7 @@ codetag_alloc_module_section(struct module *mod, const char *name, unsigned long align) { return NULL; } static inline void codetag_free_module_sections(struct module *mod) {} static inline void codetag_module_replaced(struct module *mod, struct module *new_mod) {} -static inline void codetag_load_module(struct module *mod) {} +static inline int codetag_load_module(struct module *mod) { return 0; } static inline void codetag_unload_module(struct module *mod) {} #endif /* defined(CONFIG_CODE_TAGGING) && defined(CONFIG_MODULES) */ diff --git a/kernel/module/main.c b/kernel/module/main.c index 5c6ab20240a6..9861c2ac5fd5 100644 --- a/kernel/module/main.c +++ b/kernel/module/main.c @@ -3399,11 +3399,12 @@ static int load_module(struct load_info *info, const char __user *uargs, goto sysfs_cleanup; } + if (codetag_load_module(mod)) + goto sysfs_cleanup; + /* Get rid of temporary copy. */ free_copy(info, flags); - codetag_load_module(mod); - /* Done! */ trace_module_load(mod); diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c index 45dae7da70e1..d48b80f3f007 100644 --- a/lib/alloc_tag.c +++ b/lib/alloc_tag.c @@ -607,15 +607,16 @@ static void release_module_tags(struct module *mod, bool used) mas_unlock(&mas); } -static void load_module(struct module *mod, struct codetag *start, struct codetag *stop) +static int load_module(struct module *mod, struct codetag *start, struct codetag *stop) { /* Allocate module alloc_tag percpu counters */ struct alloc_tag *start_tag; struct alloc_tag *stop_tag; struct alloc_tag *tag; + /* percpu counters for core allocations are already statically allocated */ if (!mod) - return; + return 0; start_tag = ct_to_alloc_tag(start); stop_tag = ct_to_alloc_tag(stop); @@ -627,12 +628,13 @@ static void load_module(struct module *mod, struct codetag *start, struct codeta free_percpu(tag->counters); tag->counters = NULL; } - shutdown_mem_profiling(true); - pr_err("Failed to allocate memory for allocation tag percpu counters in the module %s. Memory allocation profiling is disabled!\n", + pr_err("Failed to allocate memory for allocation tag percpu counters in the module %s\n", mod->name); - break; + return -ENOMEM; } } + + return 0; } static void replace_module(struct module *mod, struct module *new_mod) diff --git a/lib/codetag.c b/lib/codetag.c index de332e98d6f5..650d54d7e14d 100644 --- a/lib/codetag.c +++ b/lib/codetag.c @@ -167,6 +167,7 @@ static int codetag_module_init(struct codetag_type *cttype, struct module *mod) { struct codetag_range range; struct codetag_module *cmod; + int mod_id; int err; range = get_section_range(mod, cttype->desc.section); @@ -190,11 +191,20 @@ static int codetag_module_init(struct codetag_type *cttype, struct module *mod) cmod->range = range; down_write(&cttype->mod_lock); - err = idr_alloc(&cttype->mod_idr, cmod, 0, 0, GFP_KERNEL); - if (err >= 0) { - cttype->count += range_size(cttype, &range); - if (cttype->desc.module_load) - cttype->desc.module_load(mod, range.start, range.stop); + mod_id = idr_alloc(&cttype->mod_idr, cmod, 0, 0, GFP_KERNEL); + if (mod_id >= 0) { + if (cttype->desc.module_load) { + err = cttype->desc.module_load(mod, range.start, range.stop); + if (!err) + cttype->count += range_size(cttype, &range); + else + idr_remove(&cttype->mod_idr, mod_id); + } else { + cttype->count += range_size(cttype, &range); + err = 0; + } + } else { + err = mod_id; } up_write(&cttype->mod_lock); @@ -295,17 +305,23 @@ void codetag_module_replaced(struct module *mod, struct module *new_mod) mutex_unlock(&codetag_lock); } -void codetag_load_module(struct module *mod) +int codetag_load_module(struct module *mod) { struct codetag_type *cttype; + int ret = 0; if (!mod) - return; + return 0; mutex_lock(&codetag_lock); - list_for_each_entry(cttype, &codetag_types, link) - codetag_module_init(cttype, mod); + list_for_each_entry(cttype, &codetag_types, link) { + ret = codetag_module_init(cttype, mod); + if (ret) + break; + } mutex_unlock(&codetag_lock); + + return ret; } void codetag_unload_module(struct module *mod) base-commit: 9f3e87f6c8d4b28b96eb8bddb22d3ba4b846e10b -- 2.49.0.1112.g889b7c5bd8-goog

5 months, 2 weeks

2
2
0 0

[PATCH v2 1/2] SUNRPC: Prevent hang on NFS mount with xprtsec=[m]tls

by cel＠kernel.org

From: Chuck Lever <chuck.lever(a)oracle.com> Engineers at Hammerspace noticed that sometimes mounting with "xprtsec=tls" hangs for a minute or so, and then times out, even when the NFS server is reachable and responsive. kTLS shuts off data_ready callbacks if strp->msg_ready is set to mitigate data_ready callbacks when a full TLS record is not yet ready to be read from the socket. Normally msg_ready is clear when the first TLS record arrives on a socket. However, I observed that sometimes tls_setsockopt() sets strp->msg_ready, and that prevents forward progress because tls_data_ready() becomes a no-op. Moreover, Jakub says: "If there's a full record queued at the time when [tlshd] passes the socket back to the kernel, it's up to the reader to read the already queued data out." So SunRPC cannot expect a data_ready call when ingress data is already waiting. Add an explicit poll after SunRPC's upper transport is set up to pick up any data that arrived after the TLS handshake but before transport set-up is complete. Reported-by: Steve Sears <sjs(a)hammerspace.com> Suggested-by: Jakub Kacinski <kuba(a)kernel.org> Fixes: 75eb6af7acdf ("SUNRPC: Add a TCP-with-TLS RPC transport class") Tested-by: Mike Snitzer <snitzer(a)kernel.org> Reviewed-by: Mike Snitzer <snitzer(a)kernel.org> Cc: stable(a)vger.kernel.org Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> --- net/sunrpc/xprtsock.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c index 83cc095846d3..4b10ecf4c265 100644 --- a/net/sunrpc/xprtsock.c +++ b/net/sunrpc/xprtsock.c @@ -2740,6 +2740,11 @@ static void xs_tcp_tls_setup_socket(struct work_struct *work) } rpc_shutdown_client(lower_clnt); + /* Check for ingress data that arrived before the socket's + * ->data_ready callback was set up. + */ + xs_poll_check_readable(upper_transport); + out_unlock: current_restore_flags(pflags, PF_MEMALLOC); upper_transport->clnt = NULL; -- 2.49.0

5 months, 2 weeks

1
0
0 0

+ alloc_tag-handle-module-codetag-load-errors-as-module-load-failures.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: alloc_tag: handle module codetag load errors as module load failures has been added to the -mm mm-hotfixes-unstable branch. Its filename is alloc_tag-handle-module-codetag-load-errors-as-module-load-failures.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: Suren Baghdasaryan <surenb(a)google.com> Subject: alloc_tag: handle module codetag load errors as module load failures Date: Wed, 21 May 2025 09:06:02 -0700 Failures inside codetag_load_module() are currently ignored. As a result an error there would not cause a module load failure and freeing of the associated resources. Correct this behavior by propagating the error code to the caller and handling possible errors. With this change, error to allocate percpu counters, which happens at this stage, will not be ignored and will cause a module load failure and freeing of resources. With this change we also do not need to disable memory allocation profiling when this error happens, instead we fail to load the module. Link: https://lkml.kernel.org/r/20250521160602.1940771-1-surenb@google.com Fixes: 10075262888b ("alloc_tag: allocate percpu counters for module tags dynamically") Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Reported-by: Casey Chen <cachen(a)purestorage.com> Closes: https://lore.kernel.org/all/20250520231620.15259-1-cachen@purestorage.com/ Cc: Daniel Gomez <da.gomez(a)samsung.com> Cc: David Wang <00107082(a)163.com> Cc: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: Luis Chamberalin <mcgrof(a)kernel.org> Cc: Petr Pavlu <petr.pavlu(a)suse.com> Cc: Sami Tolvanen <samitolvanen(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/codetag.h | 8 ++++---- kernel/module/main.c | 5 +++-- lib/alloc_tag.c | 12 +++++++----- lib/codetag.c | 34 +++++++++++++++++++++++++--------- 4 files changed, 39 insertions(+), 20 deletions(-) --- a/include/linux/codetag.h~alloc_tag-handle-module-codetag-load-errors-as-module-load-failures +++ a/include/linux/codetag.h @@ -36,8 +36,8 @@ union codetag_ref { struct codetag_type_desc { const char *section; size_t tag_size; - void (*module_load)(struct module *mod, - struct codetag *start, struct codetag *end); + int (*module_load)(struct module *mod, + struct codetag *start, struct codetag *end); void (*module_unload)(struct module *mod, struct codetag *start, struct codetag *end); #ifdef CONFIG_MODULES @@ -89,7 +89,7 @@ void *codetag_alloc_module_section(struc unsigned long align); void codetag_free_module_sections(struct module *mod); void codetag_module_replaced(struct module *mod, struct module *new_mod); -void codetag_load_module(struct module *mod); +int codetag_load_module(struct module *mod); void codetag_unload_module(struct module *mod); #else /* defined(CONFIG_CODE_TAGGING) && defined(CONFIG_MODULES) */ @@ -103,7 +103,7 @@ codetag_alloc_module_section(struct modu unsigned long align) { return NULL; } static inline void codetag_free_module_sections(struct module *mod) {} static inline void codetag_module_replaced(struct module *mod, struct module *new_mod) {} -static inline void codetag_load_module(struct module *mod) {} +static inline int codetag_load_module(struct module *mod) { return 0; } static inline void codetag_unload_module(struct module *mod) {} #endif /* defined(CONFIG_CODE_TAGGING) && defined(CONFIG_MODULES) */ --- a/kernel/module/main.c~alloc_tag-handle-module-codetag-load-errors-as-module-load-failures +++ a/kernel/module/main.c @@ -3399,11 +3399,12 @@ static int load_module(struct load_info goto sysfs_cleanup; } + if (codetag_load_module(mod)) + goto sysfs_cleanup; + /* Get rid of temporary copy. */ free_copy(info, flags); - codetag_load_module(mod); - /* Done! */ trace_module_load(mod); --- a/lib/alloc_tag.c~alloc_tag-handle-module-codetag-load-errors-as-module-load-failures +++ a/lib/alloc_tag.c @@ -618,15 +618,16 @@ out: mas_unlock(&mas); } -static void load_module(struct module *mod, struct codetag *start, struct codetag *stop) +static int load_module(struct module *mod, struct codetag *start, struct codetag *stop) { /* Allocate module alloc_tag percpu counters */ struct alloc_tag *start_tag; struct alloc_tag *stop_tag; struct alloc_tag *tag; + /* percpu counters for core allocations are already statically allocated */ if (!mod) - return; + return 0; start_tag = ct_to_alloc_tag(start); stop_tag = ct_to_alloc_tag(stop); @@ -638,12 +639,13 @@ static void load_module(struct module *m free_percpu(tag->counters); tag->counters = NULL; } - shutdown_mem_profiling(true); - pr_err("Failed to allocate memory for allocation tag percpu counters in the module %s. Memory allocation profiling is disabled!\n", + pr_err("Failed to allocate memory for allocation tag percpu counters in the module %s\n", mod->name); - break; + return -ENOMEM; } } + + return 0; } static void replace_module(struct module *mod, struct module *new_mod) --- a/lib/codetag.c~alloc_tag-handle-module-codetag-load-errors-as-module-load-failures +++ a/lib/codetag.c @@ -167,6 +167,7 @@ static int codetag_module_init(struct co { struct codetag_range range; struct codetag_module *cmod; + int mod_id; int err; range = get_section_range(mod, cttype->desc.section); @@ -190,11 +191,20 @@ static int codetag_module_init(struct co cmod->range = range; down_write(&cttype->mod_lock); - err = idr_alloc(&cttype->mod_idr, cmod, 0, 0, GFP_KERNEL); - if (err >= 0) { - cttype->count += range_size(cttype, &range); - if (cttype->desc.module_load) - cttype->desc.module_load(mod, range.start, range.stop); + mod_id = idr_alloc(&cttype->mod_idr, cmod, 0, 0, GFP_KERNEL); + if (mod_id >= 0) { + if (cttype->desc.module_load) { + err = cttype->desc.module_load(mod, range.start, range.stop); + if (!err) + cttype->count += range_size(cttype, &range); + else + idr_remove(&cttype->mod_idr, mod_id); + } else { + cttype->count += range_size(cttype, &range); + err = 0; + } + } else { + err = mod_id; } up_write(&cttype->mod_lock); @@ -295,17 +305,23 @@ void codetag_module_replaced(struct modu mutex_unlock(&codetag_lock); } -void codetag_load_module(struct module *mod) +int codetag_load_module(struct module *mod) { struct codetag_type *cttype; + int ret = 0; if (!mod) - return; + return 0; mutex_lock(&codetag_lock); - list_for_each_entry(cttype, &codetag_types, link) - codetag_module_init(cttype, mod); + list_for_each_entry(cttype, &codetag_types, link) { + ret = codetag_module_init(cttype, mod); + if (ret) + break; + } mutex_unlock(&codetag_lock); + + return ret; } void codetag_unload_module(struct module *mod) _ Patches currently in -mm which might be from surenb(a)google.com are alloc_tag-allocate-percpu-counters-for-module-tags-dynamically.patch alloc_tag-handle-module-codetag-load-errors-as-module-load-failures.patch

5 months, 2 weeks

1
0
0 0

dot files in cifs mounted share

by bd730c5053df9efb

Hi! I upgraded the stock kernel on my slackware machine from 5.15.161 to 6.12.16 and I realized that I was not being able to create dot files in a cifs mounted volume. I just updated the kernel to 6.12.29 and I find the same behavior. The share is exported from a samba machine whose smb.conf file is the following (redacted for privacy) [global] security = ADS workgroup = ADDOMAIN realm = ADDOMAIN.COM username map = /etc/samba/user.map kerberos method = secrets and keytab winbind refresh tickets = Yes winbind expand groups = 2 winbind offline logon = Yes # winbind enum users = Yes # winbind enum groups = Yes dedicated keytab file = /etc/krb5.keytab idmap config * : backend = tdb idmap config * : range = 3000-7999 idmap config addomain:backend = ad idmap config addomain:schema_mode = rfc2307 idmap config addomain:range = 10000-999999 idmap config addomain:unix_nss_info = Yes vfs objects = acl_xattr map acl inherit = Yes store dos attributes = Yes printing = CUPS log level = 1 auth:3 auth_audit:3 auth_json_audit:3 rpc_server:spoolss = external rpc_daemon:spoolssd = fork spoolssd:prefork_min_children = 5 spoolssd:prefork_max_children = 25 spoolssd:prefork_spawn_rate = 5 spoolssd:prefork_max_allowed_clients = 100 spoolssd:prefork_child_min_life = 60 ntlm auth = mschapv2-and-ntlmv2-only [printers] path = /var/spool/samba printable = Yes [print$] path = /srv/samba/printer_drivers read only = No [users] path = /home/users read only = No [Publicas] path = /home/shares/publicas read only = No The client is succesfully joined to the domain and the shares are mounted with the following parameters (redacted for privacy) //fileserver.addomain.com/Users/username on /home/username/.Documents type cifs (rw,relatime,vers=3.1.1,cache=strict,username=username,domain=ADDOMAIN,uid=11002,forceuid,gid=10513,forcegid,addr=192.168.25.6,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,reparse=nfs,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1) //fileserver.addomain.com/Publicas on /home/username/Public type cifs (rw,relatime,vers=3.1.1,cache=strict,username=username,domain=ADDOMAIN,uid=11002,forceuid,gid=10513,forcegid,addr=192.168.25.6,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,reparse=nfs,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=60,actimeo=1,closetimeo=1) If I issue the following command cd /home/username/.Documents/ touch .foo.bar (this file doesn't exist on the volume) I get the following error "touch: cannot touch '.foo.bar': Permission denied" When I increase the debug by issuing the following command all echo 7 > /proc/fs/cifs/cifsFYI All I get in dmesg is [ 2702.654271] CIFS: Status code returned 0xc0000034 STATUS_OBJECT_NAME_NOT_FOUND However the even weirder part is that on the "Publicas" volume I have no such issue cd /home/username/Public/ touch ./.foo.bar ls -alt -rwxr-xr-x 1 ADDOMAIN\username ADDOMAIN\domain users 0 may 21 14:57 .foo.bar If I boot back 5.15.161 I have no such problem. Thanks in advance! Best regards, Dave.

5 months, 2 weeks

1
0
0 0

[PATCH] mmc: core: sd: Apply BROKEN_SD_DISCARD quirk earlier

by Avri Altman

Move the BROKEN_SD_DISCARD quirk for certain SanDisk SD cards from the `mmc_blk_fixups[]` to `mmc_sd_fixups[]`. This ensures the quirk is applied earlier in the device initialization process, aligning with the reasoning in [1]. Applying the quirk sooner prevents the kernel from incorrectly enabling discard support on affected cards during initial setup. [1] https://lore.kernel.org/all/20240820230631.GA436523@sony.com Fixes: 07d2872bf4c8 ("mmc: core: Add SD card quirk for broken discard") Signed-off-by: Avri Altman <avri.altman(a)sandisk.com> Cc: stable(a)vger.kernel.org --- drivers/mmc/core/quirks.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h index 7f893bafaa60..c417ed34c057 100644 --- a/drivers/mmc/core/quirks.h +++ b/drivers/mmc/core/quirks.h @@ -44,6 +44,12 @@ static const struct mmc_fixup __maybe_unused mmc_sd_fixups[] = { 0, -1ull, SDIO_ANY_ID, SDIO_ANY_ID, add_quirk_sd, MMC_QUIRK_NO_UHS_DDR50_TUNING, EXT_CSD_REV_ANY), + /* + * Some SD cards reports discard support while they don't + */ + MMC_FIXUP(CID_NAME_ANY, CID_MANFID_SANDISK_SD, 0x5344, add_quirk_sd, + MMC_QUIRK_BROKEN_SD_DISCARD), + END_FIXUP }; @@ -147,12 +153,6 @@ static const struct mmc_fixup __maybe_unused mmc_blk_fixups[] = { MMC_FIXUP("M62704", CID_MANFID_KINGSTON, 0x0100, add_quirk_mmc, MMC_QUIRK_TRIM_BROKEN), - /* - * Some SD cards reports discard support while they don't - */ - MMC_FIXUP(CID_NAME_ANY, CID_MANFID_SANDISK_SD, 0x5344, add_quirk_sd, - MMC_QUIRK_BROKEN_SD_DISCARD), - END_FIXUP }; -- 2.25.1

5 months, 2 weeks

3
2
0 0

[PATCH 5.15 0/1] Oopses on module unload seen on 5.15-rc

by Fedor Pchelkin

A followup to the similar patch sent to 6.1.y: https://lore.kernel.org/stable/20250521165909.834545-1-pchelkin@ispras.ru/ commit 959cadf09dbae7b304f03e039b8d8e13c529e2dd Author: Peter Zijlstra <peterz(a)infradead.org> Date: Mon Oct 14 10:05:48 2024 -0700 x86/its: Use dynamic thunks for indirect branches commit 872df34d7c51a79523820ea6a14860398c639b87 upstream. being ported to 5.15.y would lead to kernel crashes there after module unload operations. As mentioned in the blamed patch comment describing the backport adaptations: [ pawan: CONFIG_EXECMEM and CONFIG_EXECMEM_ROX are not supported on backport kernel, made changes to use module_alloc() and set_memory_*() for dynamic thunks. ] module_alloc/module_memfree in conjunction with memory protection routines were used. The allocated memory is vmalloc-based, and it ends up being ROX upon release inside its_free_mod(). Freeing of special permissioned memory in vmalloc requires its own handling. VM_FLUSH_RESET_PERMS flag was introduced for these purposes. In-kernel users dealing with the stuff had to care about this explicitly before commit 4c4eb3ecc91f ("x86/modules: Set VM_FLUSH_RESET_PERMS in module_alloc()"). It fixes the current problem. More recent kernels starting from 6.2 have the commit and are not affected. Found by Linux Verification Center (linuxtesting.org). Thomas Gleixner (1): x86/modules: Set VM_FLUSH_RESET_PERMS in module_alloc() arch/x86/kernel/ftrace.c | 2 -- arch/x86/kernel/kprobes/core.c | 1 - arch/x86/kernel/module.c | 9 +++++---- 3 files changed, 5 insertions(+), 7 deletions(-) -- 2.49.0

5 months, 2 weeks

1
1
0 0

Re: [PATCH v1] virtio_blk: Fix disk deletion hang on device surprise removal

by Michael S. Tsirkin

On Wed, May 21, 2025 at 06:37:41AM +0000, Parav Pandit wrote: > When the PCI device is surprise removed, requests may not complete > the device as the VQ is marked as broken. Due to this, the disk > deletion hangs. > > Fix it by aborting the requests when the VQ is broken. > > With this fix now fio completes swiftly. > An alternative of IO timeout has been considered, however > when the driver knows about unresponsive block device, swiftly clearing > them enables users and upper layers to react quickly. > > Verified with multiple device unplug iterations with pending requests in > virtio used ring and some pending with the device. > > Fixes: 43bb40c5b926 ("virtio_pci: Support surprise removal of virtio pci device") > Cc: stable(a)vger.kernel.org > Reported-by: lirongqing(a)baidu.com > Closes: https://lore.kernel.org/virtualization/c45dd68698cd47238c55fb73ca9b4741@bai… > Reviewed-by: Max Gurtovoy <mgurtovoy(a)nvidia.com> > Reviewed-by: Israel Rukshin <israelr(a)nvidia.com> > Signed-off-by: Parav Pandit <parav(a)nvidia.com> > --- > changelog: > v0->v1: > - Fixed comments from Stefan to rename a cleanup function > - Improved logic for handling any outstanding requests > in bio layer > - improved cancel callback to sync with ongoing done() thanks for the patch! questions: > --- > drivers/block/virtio_blk.c | 95 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 95 insertions(+) > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > index 7cffea01d868..5212afdbd3c7 100644 > --- a/drivers/block/virtio_blk.c > +++ b/drivers/block/virtio_blk.c > @@ -435,6 +435,13 @@ static blk_status_t virtio_queue_rq(struct blk_mq_hw_ctx *hctx, > blk_status_t status; > int err; > > + /* Immediately fail all incoming requests if the vq is broken. > + * Once the queue is unquiesced, upper block layer flushes any pending > + * queued requests; fail them right away. > + */ > + if (unlikely(virtqueue_is_broken(vblk->vqs[qid].vq))) > + return BLK_STS_IOERR; > + > status = virtblk_prep_rq(hctx, vblk, req, vbr); > if (unlikely(status)) > return status; just below this: spin_lock_irqsave(&vblk->vqs[qid].lock, flags); err = virtblk_add_req(vblk->vqs[qid].vq, vbr); if (err) { and virtblk_add_req calls virtqueue_add_sgs, so it will fail on a broken vq. Why do we need to check it one extra time here? > @@ -508,6 +515,11 @@ static void virtio_queue_rqs(struct rq_list *rqlist) > while ((req = rq_list_pop(rqlist))) { > struct virtio_blk_vq *this_vq = get_virtio_blk_vq(req->mq_hctx); > > + if (unlikely(virtqueue_is_broken(this_vq->vq))) { > + rq_list_add_tail(&requeue_list, req); > + continue; > + } > + > if (vq && vq != this_vq) > virtblk_add_req_batch(vq, &submit_list); > vq = this_vq; similarly > @@ -1554,6 +1566,87 @@ static int virtblk_probe(struct virtio_device *vdev) > return err; > } > > +static bool virtblk_request_cancel(struct request *rq, void *data) > +{ > + struct virtblk_req *vbr = blk_mq_rq_to_pdu(rq); > + struct virtio_blk *vblk = data; > + struct virtio_blk_vq *vq; > + unsigned long flags; > + > + vq = &vblk->vqs[rq->mq_hctx->queue_num]; > + > + spin_lock_irqsave(&vq->lock, flags); > + > + vbr->in_hdr.status = VIRTIO_BLK_S_IOERR; > + if (blk_mq_request_started(rq) && !blk_mq_request_completed(rq)) > + blk_mq_complete_request(rq); > + > + spin_unlock_irqrestore(&vq->lock, flags); > + return true; > +} > + > +static void virtblk_broken_device_cleanup(struct virtio_blk *vblk) > +{ > + struct request_queue *q = vblk->disk->queue; > + > + if (!virtqueue_is_broken(vblk->vqs[0].vq)) > + return; > + > + /* Start freezing the queue, so that new requests keeps waitng at the > + * door of bio_queue_enter(). We cannot fully freeze the queue because > + * freezed queue is an empty queue and there are pending requests, so > + * only start freezing it. > + */ > + blk_freeze_queue_start(q); > + > + /* When quiescing completes, all ongoing dispatches have completed > + * and no new dispatch will happen towards the driver. > + * This ensures that later when cancel is attempted, then are not > + * getting processed by the queue_rq() or queue_rqs() handlers. > + */ > + blk_mq_quiesce_queue(q); > + > + /* > + * Synchronize with any ongoing VQ callbacks, effectively quiescing > + * the device and preventing it from completing further requests > + * to the block layer. Any outstanding, incomplete requests will be > + * completed by virtblk_request_cancel(). > + */ > + virtio_synchronize_cbs(vblk->vdev); > + > + /* At this point, no new requests can enter the queue_rq() and > + * completion routine will not complete any new requests either for the > + * broken vq. Hence, it is safe to cancel all requests which are > + * started. > + */ > + blk_mq_tagset_busy_iter(&vblk->tag_set, virtblk_request_cancel, vblk); > + blk_mq_tagset_wait_completed_request(&vblk->tag_set); > + > + /* All pending requests are cleaned up. Time to resume so that disk > + * deletion can be smooth. Start the HW queues so that when queue is > + * unquiesced requests can again enter the driver. > + */ > + blk_mq_start_stopped_hw_queues(q, true); > + > + /* Unquiescing will trigger dispatching any pending requests to the > + * driver which has crossed bio_queue_enter() to the driver. > + */ > + blk_mq_unquiesce_queue(q); > + > + /* Wait for all pending dispatches to terminate which may have been > + * initiated after unquiescing. > + */ > + blk_mq_freeze_queue_wait(q); > + > + /* Mark the disk dead so that once queue unfreeze, the requests > + * waiting at the door of bio_queue_enter() can be aborted right away. > + */ > + blk_mark_disk_dead(vblk->disk); > + > + /* Unfreeze the queue so that any waiting requests will be aborted. */ > + blk_mq_unfreeze_queue_nomemrestore(q); > +} > + > static void virtblk_remove(struct virtio_device *vdev) > { > struct virtio_blk *vblk = vdev->priv; > @@ -1561,6 +1654,8 @@ static void virtblk_remove(struct virtio_device *vdev) > /* Make sure no work handler is accessing the device. */ > flush_work(&vblk->config_work); > > + virtblk_broken_device_cleanup(vblk); > + > del_gendisk(vblk->disk); > blk_mq_free_tag_set(&vblk->tag_set); > > -- > 2.34.1

5 months, 2 weeks

2
8
0 0

FAILED: patch "[PATCH] drm/amdgpu: read back register after written for VCN v4.0.5" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x ee7360fc27d6045510f8fe459b5649b2af27811a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025052140-handsaw-train-2343@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ee7360fc27d6045510f8fe459b5649b2af27811a Mon Sep 17 00:00:00 2001 From: "David (Ming Qiang) Wu" <David.Wu3(a)amd.com> Date: Mon, 12 May 2025 15:14:43 -0400 Subject: [PATCH] drm/amdgpu: read back register after written for VCN v4.0.5 On VCN v4.0.5 there is a race condition where the WPTR is not updated after starting from idle when doorbell is used. Adding register read-back after written at function end is to ensure all register writes are done before they can be used. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12528 Signed-off-by: David (Ming Qiang) Wu <David.Wu3(a)amd.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Tested-by: Mario Limonciello <mario.limonciello(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Ruijing Dong <ruijing.dong(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 07c9db090b86e5211188e1b351303fbc673378cf) Cc: stable(a)vger.kernel.org diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c index a1171e6152ed..f11df9c2ec13 100644 --- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c @@ -1023,6 +1023,10 @@ static int vcn_v4_0_5_start_dpg_mode(struct amdgpu_vcn_inst *vinst, ring->doorbell_index << VCN_RB1_DB_CTRL__OFFSET__SHIFT | VCN_RB1_DB_CTRL__EN_MASK); + /* Keeping one read-back to ensure all register writes are done, otherwise + * it may introduce race conditions */ + RREG32_SOC15(VCN, inst_idx, regVCN_RB1_DB_CTRL); + return 0; } @@ -1205,6 +1209,10 @@ static int vcn_v4_0_5_start(struct amdgpu_vcn_inst *vinst) WREG32_SOC15(VCN, i, regVCN_RB_ENABLE, tmp); fw_shared->sq.queue_mode &= ~(FW_QUEUE_RING_RESET | FW_QUEUE_DPG_HOLD_OFF); + /* Keeping one read-back to ensure all register writes are done, otherwise + * it may introduce race conditions */ + RREG32_SOC15(VCN, i, regVCN_RB_ENABLE); + return 0; }

5 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025