Re: [ANNOUNCE] v5.14-rc5-rt8

[Vlastimil Babka]

On 8/12/21 11:44 PM, Clark Williams wrote:
> On Thu, 12 Aug 2021 23:30:29 +0200
> Vlastimil Babka <vbabka@xxxxxxx> wrote:
> 
>> On 8/12/21 11:24 PM, Clark Williams wrote:
>>> On Thu, 12 Aug 2021 22:45:19 +0200
>>> Vlastimil Babka <vbabka@xxxxxxx> wrote:
>>>   
>>>> On 8/12/21 10:18 PM, Clark Williams wrote:  
>>>>> On Tue, 10 Aug 2021 18:37:31 +0200
>>>>> Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote:
>>>>>
>>>>> Sebastian, et al,
>>>>>
>>>>> Got the following panic running v5.14-rc5-rt8:
>>>>>
>>>>> Aug 13 06:35:05 oberon kernel: page:000000009ac5dd73 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ab3db
>>>>> Aug 13 06:35:05 oberon kernel: flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)
>>>>> Aug 13 06:35:05 oberon kernel: raw: 0017ffffc0000000 ffffee1286aceb88 ffffee1287b66288 0000000000000000
>>>>> Aug 13 06:35:05 oberon kernel: raw: 0000000000000000 0000000000100000 00000000ffffffff 0000000000000000
>>>>> Aug 13 06:35:05 oberon kernel: page dumped because: VM_BUG_ON_PAGE(!PageSlab(page))
>>>>> Aug 13 06:35:05 oberon kernel: ------------[ cut here ]------------
>>>>> Aug 13 06:35:05 oberon kernel: kernel BUG at include/linux/page-flags.h:814!
>>>>> Aug 13 06:35:05 oberon kernel: invalid opcode: 0000 [#1] PREEMPT_RT SMP PTI
>>>>> Aug 13 06:35:05 oberon kernel: CPU: 3 PID: 12345 Comm: hackbench Not tainted 5.14.0-rc5-rt8+ #12
>>>>> Aug 13 06:35:05 oberon kernel: Hardware name:  /NUC5i7RYB, BIOS RYBDWi35.86A.0359.2016.0906.1028 09/06/2016
>>>>> Aug 13 06:35:05 oberon kernel: RIP: 0010:___slab_alloc+0x340/0x940    
>>>>
>>>> Are you able to translate this RIP via addr2line?  
>>>
>>> $ addr2line -e /data/o/linux-5.14.y-rt/vmlinux ___slab_alloc+0x340/0x940
>>> <snip>/arch/x86/include/asm/processor.h:440  
>>
>> Hm that's not much useful, I'd need the line in mm/slub.c
>> does ./scripts/faddr2line give better output?
> 
> Why, yes it does!  :)
> 
> $ ./scripts/faddr2line /data/o/linux-5.14.y-rt/vmlinux ___slab_alloc+0x340/0x940
> ___slab_alloc+0x340/0x940:
> PageSlabPfmemalloc at include/linux/page-flags.h:814
> (inlined by) pfmemalloc_match at mm/slub.c:2772
> (inlined by) ___slab_alloc at mm/slub.c:2874

Aha! That's helpful. Hopefully it's just a small issue where we
opportunistically test flags on a page that's protected by the local
lock we didn't take yet, and I didn't realize there's the VM_BUG_ON
which can trigger if our page went away (which we would have realized
after taking the lock).

So hopefully the below diff with uninspired naming should help?

----8<----
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 5922031ffab6..24579f71001e 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -815,6 +815,11 @@ static inline int PageSlabPfmemalloc(struct page *page)
 	return PageActive(page);
 }
 
+static inline int __PageSlabPfmemalloc(struct page *page)
+{
+	return PageActive(page);
+}
+
 static inline void SetPageSlabPfmemalloc(struct page *page)
 {
 	VM_BUG_ON_PAGE(!PageSlab(page), page);
diff --git a/mm/slub.c b/mm/slub.c
index ef022fe159c6..3cc7d58a08fa 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2775,6 +2775,14 @@ static inline bool pfmemalloc_match(struct page *page, gfp_t gfpflags)
 	return true;
 }
 
+static inline bool try_pfmemalloc_match(struct page *page, gfp_t gfpflags)
+{
+	if (unlikely(__PageSlabPfmemalloc(page)))
+		return gfp_pfmemalloc_allowed(gfpflags);
+
+	return true;
+}
+
 /*
  * Check the page->freelist of a page and either transfer the freelist to the
  * per cpu freelist or deactivate the page.
@@ -2871,7 +2879,7 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
 	 * PFMEMALLOC but right now, we are losing the pfmemalloc
 	 * information when the page leaves the per-cpu allocator
 	 */
-	if (unlikely(!pfmemalloc_match(page, gfpflags)))
+	if (unlikely(!try_pfmemalloc_match(page, gfpflags)))
 		goto deactivate_slab;
 
 	/* must check again c->page in case we got preempted and it changed */