Re: [syzbot] [mm?] WARNING in mas_nomem
"Liam R. Howlett" <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.mm |
|---|---|
| Message-ID | <hg73nwj6fdkqect6xzf34i7e4ki5izjyzb3lz6ery62sq3566k@i7tsboqhsdxd> |
On 26/08/05 10:01AM, Vlastimil Babka (SUSE) wrote: > On 8/5/26 02:46, Jason Gunthorpe wrote: > > On Fri, Jul 31, 2026 at 06:07:24PM +0200, Vlastimil Babka (SUSE) wrote: > > > >> > Thanks to Vlastimil and Pedro for the help on the plan. > >> > > >> > Summary of previous conversation is here: > >> > https://lore.kernel.org/all/[email protected]/ > >> > >> Yeah, unfortunately, "too small to fail" is a lie, because in some cases it > >> can fail (such as the task itself becoming oom killer victim) or any of the > >> other conditions that can cause __alloc_pages_may_oom() return with > >> *did_some_progress == 0. > > > > But then we are back to the original problem, an erase API that can > > fail is fundamentally broken. > > That's why the plan is to add __GFP_NOFAIL, which overrides the > possibilities to fail listed above. > Something like the attached.
0001-maple_tree-Remove-warning-from-mas_nomem.patch
(text/x-diff, 2.3 KB)
From 7943966dfd4eb8470d79da1fef2d81cf4cf59983 Mon Sep 17 00:00:00 2001 From: "Liam R. Howlett (Oracle)" <[email protected]> Date: Thu, 6 Aug 2026 10:23:00 -0400 Subject: [PATCH] maple_tree: Remove warning from mas_nomem() It is possible to trigger the warning in mas_nomem in certain call paths using valid gfp flags. Drop the warning and handle the failures differently. Instead, have mtree_erase() and mas_erase() use __GFP_NOFAIL. During the discussion, mas_store() was also flagged as a potential path that may fail due to implied gfp flags. Changing those flags to retry with __GFP_NOFAIL is a viable solution there. At the same time, adding a might_sleep() check to catch incorrect uses is prudent. Signed-off-by: Liam R. Howlett (Oracle) <[email protected]> --- lib/maple_tree.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/lib/maple_tree.c b/lib/maple_tree.c index 0954d431bf981..4fb7a209dcb2d 100644 --- a/lib/maple_tree.c +++ b/lib/maple_tree.c @@ -5577,6 +5577,9 @@ void *mas_store(struct ma_state *mas, void *entry) MA_WR_STATE(wr_mas, mas, entry); mas_may_init_lock_check(mas); + if (mt_external_lock(mas->tree)) + might_alloc(GFP_KERNEL); + trace_ma_write(TP_FCT, mas, 0, entry); #ifdef CONFIG_DEBUG_MAPLE_TREE if (MAS_WARN_ON(mas, mas->index > mas->last)) @@ -5609,8 +5612,7 @@ void *mas_store(struct ma_state *mas, void *entry) goto store; mas_alloc_nodes(mas, GFP_NOWAIT); - if (mas_is_err(mas)) - return NULL; + mas_nomem(mas, GFP_KERNEL | __GFP_NOFAIL); store: mas_wr_store_entry(&wr_mas); @@ -6351,7 +6353,7 @@ void *mas_erase(struct ma_state *mas) /* Must reset to ensure spanning writes of last slot are detected */ mas_reset(mas); mas_wr_preallocate(&wr_mas, NULL); - if (mas_nomem(mas, GFP_KERNEL)) { + if (mas_nomem(mas, GFP_KERNEL | __GFP_NOFAIL)) { /* in case the range of entry changed when unlocked */ mas->index = mas->last = index; goto write_retry; @@ -6402,7 +6404,7 @@ bool mas_nomem(struct ma_state *mas, gfp_t gfp) * external lock with a non-blocking gfp in a low memory situation - * which would have triggered the first warning in this function. */ - if (WARN_ON_ONCE(!mas->sheaf && !mas->alloc)) + if (!mas->sheaf && !mas->alloc) return false; mas_reset(mas); -- 2.47.3