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

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Apr 22, 2025 at 05:39:52AM +0930, Qu Wenruo wrote:
> 
> 
> 在 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?

Yeah.  I think willy thinks this is an implementation bug in readahead,
so it'll probably get fixed sooner or later.

--D

> 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
> > > 
> > 
>