Sleep inside atomic for aarch64, triggered by generic/482

Sleep inside atomic for aarch64, triggered by generic/482

[Qu Wenruo]

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)

- 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

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

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

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
> 

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

[Qu Wenruo]

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

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

[Darrick J. Wong]

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