Re: [PATCH 0/5] Remove some races around folio_test_hugetlb

[Miaohe Lin <linmiaohe@huawei.com>]

On 2024/3/5 1:08, Matthew Wilcox wrote:
> On Mon, Mar 04, 2024 at 05:09:58PM +0800, Miaohe Lin wrote:
>> I encountered similar issues with PageSwapCache check when doing memory-failure test:
>>
>> [66258.945079] page:00000000135e1205 refcount:1 mapcount:0 mapping:0000000000000000 index:0x9b pfn:0xa04e9a
>> [66258.949096] head:0000000038449724 order:9 entire_mapcount:1 nr_pages_mapped:0 pincount:0
>> [66258.949485] memcg:ffff95fb43379000
>> [66258.950334] anon flags: 0x6fffc00000a0068(uptodate|lru|head|mappedtodisk|swapbacked|node=1|zone=2|lastcpupid=0x3fff)
>> [66258.951212] page_type: 0xffffffff()
>> [66258.951882] raw: 06fffc0000000000 ffffc89628138001 dead000000000122 dead000000000400
>> [66258.952273] raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
>> [66258.952884] head: 06fffc00000a0068 ffffc896218a8008 ffffc89621680008 ffff95fb4349c439
>> [66258.953239] head: 0000000700000600 0000000000000000 00000001ffffffff ffff95fb43379000
>> [66258.953725] page dumped because: VM_BUG_ON_PAGE(PageTail(page))
>> [66258.954497] ------------[ cut here ]------------
>> [66258.954937] kernel BUG at include/linux/page-flags.h:313!
>> [66258.956502] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
>> [66258.957001] CPU: 14 PID: 174237 Comm: page-types Kdump: loaded Not tainted 6.8.0-rc1-00162-gd162e170f118 #11
>> [66258.957001] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
>> [66258.958415] RIP: 0010:folio_flags.constprop.0+0x1c/0x50
>> [66258.958415] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 8b 57 08 48 89 f8 83 e2 01 74 12 48 c7 c6 a0 59 34 a7 48 89 c7 e8 b5 60 e8 ff 90 <0f> 0b 66 90 c3 cc cc cc cc f7 c7 ff 0f 00 00 75 1a 48 8b 17 83 e2
>> [66258.958415] RSP: 0018:ffffa0f38ae53e00 EFLAGS: 00000282
>> [66258.958415] RAX: 0000000000000033 RBX: 0000000000000000 RCX: ffff96031fd9c9c8
>> [66258.958415] RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff96031fd9c9c0
>> [66258.958415] RBP: ffffc8962813a680 R08: ffffffffa7756f88 R09: 0000000000009ffb
>> [66258.962155] R10: 000000000000054a R11: ffffffffa7726fa0 R12: 06fffc0000000000
>> [66258.962155] R13: 0000000000000000 R14: 00007fff93bf1348 R15: 0000000000a04e9a
>> [66258.962155] FS:  00007f47cc5c4740(0000) GS:ffff96031fd80000(0000) knlGS:0000000000000000
>> [66258.962155] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [66258.962155] CR2: 00007fff93c7b000 CR3: 0000000850c28000 CR4: 00000000000006f0
>> [66258.962155] Call Trace:
>> [66258.962155]  <TASK>
>> [66258.965730]  stable_page_flags+0x210/0x940
>> [66258.965730]  kpageflags_read+0x97/0xf0
> 
> Clearly nobody has loved kpageflags_read() in a long time.  It's
> absolutely full of bugs, some harmless, others less so.
> 
> The heart of the problem is that nobody has a refcount on the page, so
> literally everything can change under us.  The old implementations of
> PageSwapCache (etc) would silently give bad information; the folio
> reimplementations warn you when you hit this race.
> 
> We have a few options:
> 
>  - We could grab a reference.  That would probaby be unwelcome.
>  - We can grab a snapshot.  Might be a bit overkill.
>  - We can grab the parts of the page/folio we need and open-code our
>    tests.  This actually seems easiest.

Option 3 should be the easiest way to fix the issue though it seems the code would be slightly ugly.
Will you send a formal patch?

Thanks Matthew!