Re: Sleep inside atomic for aarch64, triggered by generic/482

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2025/4/22 02:59, Darrick J. Wong 写道:
> On Sun, Apr 20, 2025 at 08:24:12PM +0930, Qu Wenruo wrote:
>> Hi,
>>
>> Recently I hit two dmesg reports from generic/482, on aarch64 64K page size
>> with 4K fs block size.
>>
>> The involved warning looks like this:
>>
>> 117645.139610] BTRFS info (device dm-13): using free-space-tree
>> [117645.146707] BTRFS info (device dm-13): start tree-log replay
>> [117645.158598] BTRFS info (device dm-13): last unmount of filesystem
>> 214efad4-5c63-49b6-ad29-f09c4966de33
>> [117645.322288] BUG: sleeping function called from invalid context at
>> mm/util.c:743
>> [117645.322312] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 46,
>> name: kcompactd0
>> [117645.322325] preempt_count: 1, expected: 0
>> [117645.322329] RCU nest depth: 0, expected: 0
>> [117645.322338] CPU: 3 UID: 0 PID: 46 Comm: kcompactd0 Tainted: G W  OE
>> 6.15.0-rc2-custom+ #116 PREEMPT(voluntary)
>> [117645.322343] Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
>> [117645.322345] Hardware name: QEMU KVM Virtual Machine, BIOS unknown
>> 2/2/2022
>> [117645.322347] Call trace:
>> [117645.322349]  show_stack+0x34/0x98 (C)
>> [117645.322360]  dump_stack_lvl+0x60/0x80
>> [117645.322366]  dump_stack+0x18/0x24
>> [117645.322370]  __might_resched+0x130/0x168
>> [117645.322375]  folio_mc_copy+0x54/0xa8
>> [117645.322382]  __migrate_folio.isra.0+0x5c/0x1f8
>> [117645.322387]  __buffer_migrate_folio+0x28c/0x2a0
>> [117645.322391]  buffer_migrate_folio_norefs+0x1c/0x30
>> [117645.322395]  move_to_new_folio+0x94/0x2c0
>> [117645.322398]  migrate_pages_batch+0x7e4/0xd10
>> [117645.322402]  migrate_pages_sync+0x88/0x240
>> [117645.322405]  migrate_pages+0x4d0/0x660
>> [117645.322409]  compact_zone+0x454/0x718
>> [117645.322414]  compact_node+0xa4/0x1b8
>> [117645.322418]  kcompactd+0x300/0x458
>> [117645.322421]  kthread+0x11c/0x140
>> [117645.322426]  ret_from_fork+0x10/0x20
>> [117645.400370] BTRFS: device fsid 214efad4-5c63-49b6-ad29-f09c4966de33
>> devid 1 transid 31 /dev/mapper/thin-vol.482 (253:13) scanned by mount
>> (924470)
>> [117645.404282] BTRFS info (device dm-13): first mount of filesystem
>> 214efad4-5c63-49b6-ad29-f09c4966de33
>>
>> Again this has no btrfs involved in the call trace.
>>
>> This looks exactly like the report here:
>>
>> https://lore.kernel.org/linux-mm/67f6e11f.050a0220.25d1c8.000b.GAE@google.com/
>>
>> However there are something new here:
>>
>> - The target fs is btrfs, no large folio support yet
>>    At least the branch I'm testing (based on v6.15-rc2) doesn't support
>>    folio.
>>
>>    Furthermore since it's btrfs, there is no buffer_head usage involved.
>>    (But the rootfs is indeed ext4)
> 
> Doesn't matter; the block device can create large folios in its page
> cache and blkid reading the bdev can create buffer heads.
> 
> willy's workaround in:
> https://lore.kernel.org/linux-fsdevel/Z_VwF1MA-R7MgDVG@casper.infradead.org/

Thanks a lot for the info.

However this also makes me wonder, what if the block size of the block 
device eventually go larger than page size?

E.g. I know some vendors (samsumg?) are pushing for larger block size, 
with that the minimal order will still be larger than page size.

Thus I guess we can not avoid it anyway?

Thanks,
Qu

> 
> works enough to make this go away.
> 
> --D
> 
>>
>> - Arm64 64K page size with 4K block size
>>    It's less common than x86_64.
>>
>> Fortunately I can reproduce the bug reliable, it takes around 3~10 runs to
>> hit it.
>>
>> Hope this report would help a little.
>> Thanks,
>> Qu
>>
>