* [BUG?] invalidate_lock not held in read_cache_folio()
@ 2026-06-08 11:24 Dev Jain
2026-06-08 12:19 ` Matthew Wilcox
0 siblings, 1 reply; 5+ messages in thread
From: Dev Jain @ 2026-06-08 11:24 UTC (permalink / raw)
To: Matthew Wilcox, Jan Kara, linux-mm, David Hildenbrand,
Ryan Roberts, LKML
Hi,
My understanding is that there are two ways we are serializing against concurrent
addition of a folio into the pagecache (see 730633f0b7f9).
The kerneldoc of read_cache_folio() says:
"Context: May sleep. Expects mapping->invalidate_lock to be held."
I put the following in __filemap_add_folio():
+ BUG_ON(!inode_is_locked(mapping->host) &&
+ !rwsem_is_locked(&mapping->invalidate_lock));
And got the following trace:
[ 0.088725] kernel BUG at mm/filemap.c:858!
[ 0.088727] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
[ 0.111312] Modules linked in:
[ 0.111437] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.1.0-rc5-00493-g65484bf449f7 #178 PREEMPT
[ 0.111801] Hardware name: linux,dummy-virt (DT)
[ 0.111987] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 0.112255] pc : __filemap_add_folio+0x5dc/0x680
[ 0.112437] lr : __filemap_add_folio+0x168/0x680
[ 0.112629] sp : ffff80008005b550
[ 0.112757] x29: ffff80008005b5b0 x28: 0000000000100cc0 x27: 00000000ffffffff
[ 0.113030] x26: 0000000000000000 x25: 0000000000000001 x24: 0000000000000000
[ 0.113312] x23: 0000000000100cc0 x22: ffff0000c2825cc8 x21: 0000000000000000
[ 0.113599] x20: fffffdffc30cd700 x19: 0000000000000000 x18: 00000000ffffffff
[ 0.113885] x17: 2e33352820736b63 x16: 6f6c62206c616369 x15: ffff80008005b4d0
[ 0.114167] x14: 0000000000000000 x13: ffff0000c34a225f x12: 0000000000000000
[ 0.114451] x11: 0000000000000000 x10: 000000000000003a x9 : ffffce3993f54940
[ 0.114759] x8 : 0000000000000000 x7 : ffff00017f3fc910 x6 : 05ffff0000000001
[ 0.115040] x5 : ffff0000c150b000 x4 : ffff80008005b610 x3 : 0000000000100cc0
[ 0.115312] x2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000
[ 0.115587] Call trace:
[ 0.115686] __filemap_add_folio+0x5dc/0x680 (P)
[ 0.115871] filemap_add_folio+0xec/0x2d0
[ 0.116031] do_read_cache_folio+0x144/0x2d8
[ 0.116194] read_cache_folio+0x1c/0x30
[ 0.116344] read_part_sector+0x4c/0xf0
[ 0.116499] read_lba+0xb0/0x1a0
[ 0.116627] efi_partition+0xa8/0x740
[ 0.116769] bdev_disk_changed+0x238/0x620
[ 0.116939] blkdev_get_whole+0xac/0x100
[ 0.117090] bdev_open+0x280/0x3c0
[ 0.117221] bdev_file_open_by_dev+0xe4/0x158
[ 0.117394] disk_scan_partitions+0x70/0x160
[ 0.117565] add_disk_fwnode+0x1a4/0x1d0
[ 0.117725] device_add_disk+0x1c/0x30
[ 0.117869] virtblk_probe+0x6a0/0x918
[ 0.118025] virtio_dev_probe+0x1c8/0x310
[ 0.118184] really_probe+0xc4/0x2b0
[ 0.118330] __driver_probe_device+0x88/0x170
[ 0.118497] driver_probe_device+0x44/0x178
[ 0.118669] __driver_attach+0x98/0x1b8
[ 0.118819] bus_for_each_dev+0x84/0xf0
[ 0.118979] driver_attach+0x2c/0x40
[ 0.119123] bus_add_driver+0xec/0x218
[ 0.119269] driver_register+0x64/0x138
[ 0.119419] __register_virtio_driver+0x2c/0x50
[ 0.119598] virtio_blk_init+0x74/0xd0
[ 0.119757] do_one_initcall+0x60/0x3f0
[ 0.119903] kernel_init_freeable+0x1f4/0x540
[ 0.120075] kernel_init+0x2c/0x1f8
[ 0.120218] ret_from_fork+0x10/0x20
[ 0.120357] Code: 9401562d d4210000 f9400ec0 b5ffdd20 (d4210000)
[ 0.120592] ---[ end trace 0000000000000000 ]---
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG?] invalidate_lock not held in read_cache_folio()
2026-06-08 11:24 [BUG?] invalidate_lock not held in read_cache_folio() Dev Jain
@ 2026-06-08 12:19 ` Matthew Wilcox
2026-06-08 13:29 ` Dev Jain
2026-06-09 11:58 ` Jan Kara
0 siblings, 2 replies; 5+ messages in thread
From: Matthew Wilcox @ 2026-06-08 12:19 UTC (permalink / raw)
To: Dev Jain; +Cc: Jan Kara, linux-mm, David Hildenbrand, Ryan Roberts, LKML
On Mon, Jun 08, 2026 at 04:54:51PM +0530, Dev Jain wrote:
> Hi,
>
> My understanding is that there are two ways we are serializing against concurrent
> addition of a folio into the pagecache (see 730633f0b7f9).
>
> The kerneldoc of read_cache_folio() says:
>
> "Context: May sleep. Expects mapping->invalidate_lock to be held."
>
> I put the following in __filemap_add_folio():
>
> + BUG_ON(!inode_is_locked(mapping->host) &&
> + !rwsem_is_locked(&mapping->invalidate_lock));
>
>
> And got the following trace:
>
>
> [ 0.115587] Call trace:
> [ 0.115686] __filemap_add_folio+0x5dc/0x680 (P)
> [ 0.115871] filemap_add_folio+0xec/0x2d0
> [ 0.116031] do_read_cache_folio+0x144/0x2d8
> [ 0.116194] read_cache_folio+0x1c/0x30
> [ 0.116344] read_part_sector+0x4c/0xf0
> [ 0.116499] read_lba+0xb0/0x1a0
> [ 0.116627] efi_partition+0xa8/0x740
> [ 0.116769] bdev_disk_changed+0x238/0x620
> [ 0.116939] blkdev_get_whole+0xac/0x100
> [ 0.117090] bdev_open+0x280/0x3c0
You can't truncate or holepunch a bdev
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG?] invalidate_lock not held in read_cache_folio()
2026-06-08 12:19 ` Matthew Wilcox
@ 2026-06-08 13:29 ` Dev Jain
2026-06-08 14:02 ` Matthew Wilcox
2026-06-09 11:58 ` Jan Kara
1 sibling, 1 reply; 5+ messages in thread
From: Dev Jain @ 2026-06-08 13:29 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Jan Kara, linux-mm, David Hildenbrand, Ryan Roberts, LKML
On 08/06/26 5:49 pm, Matthew Wilcox wrote:
> On Mon, Jun 08, 2026 at 04:54:51PM +0530, Dev Jain wrote:
>> Hi,
>>
>> My understanding is that there are two ways we are serializing against concurrent
>> addition of a folio into the pagecache (see 730633f0b7f9).
>>
>> The kerneldoc of read_cache_folio() says:
>>
>> "Context: May sleep. Expects mapping->invalidate_lock to be held."
>>
>> I put the following in __filemap_add_folio():
>>
>> + BUG_ON(!inode_is_locked(mapping->host) &&
>> + !rwsem_is_locked(&mapping->invalidate_lock));
>>
>>
>> And got the following trace:
>>
>>
>> [ 0.115587] Call trace:
>> [ 0.115686] __filemap_add_folio+0x5dc/0x680 (P)
>> [ 0.115871] filemap_add_folio+0xec/0x2d0
>> [ 0.116031] do_read_cache_folio+0x144/0x2d8
>> [ 0.116194] read_cache_folio+0x1c/0x30
>> [ 0.116344] read_part_sector+0x4c/0xf0
>> [ 0.116499] read_lba+0xb0/0x1a0
>> [ 0.116627] efi_partition+0xa8/0x740
>> [ 0.116769] bdev_disk_changed+0x238/0x620
>> [ 0.116939] blkdev_get_whole+0xac/0x100
>> [ 0.117090] bdev_open+0x280/0x3c0
>
> You can't truncate or holepunch a bdev
Yep, I realized that later, thanks : )
Just that the kerneldoc says "Expects mapping->invalidate_lock to be held"
so was wondering whether this comment is appropriate. Difficult for me to
reason about that since this goes into fs/block code.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG?] invalidate_lock not held in read_cache_folio()
2026-06-08 13:29 ` Dev Jain
@ 2026-06-08 14:02 ` Matthew Wilcox
0 siblings, 0 replies; 5+ messages in thread
From: Matthew Wilcox @ 2026-06-08 14:02 UTC (permalink / raw)
To: Dev Jain; +Cc: Jan Kara, linux-mm, David Hildenbrand, Ryan Roberts, LKML
On Mon, Jun 08, 2026 at 06:59:46PM +0530, Dev Jain wrote:
>
>
> On 08/06/26 5:49 pm, Matthew Wilcox wrote:
> > On Mon, Jun 08, 2026 at 04:54:51PM +0530, Dev Jain wrote:
> >> Hi,
> >>
> >> My understanding is that there are two ways we are serializing against concurrent
> >> addition of a folio into the pagecache (see 730633f0b7f9).
> >>
> >> The kerneldoc of read_cache_folio() says:
> >>
> >> "Context: May sleep. Expects mapping->invalidate_lock to be held."
> >>
> >> I put the following in __filemap_add_folio():
> >>
> >> + BUG_ON(!inode_is_locked(mapping->host) &&
> >> + !rwsem_is_locked(&mapping->invalidate_lock));
> >>
> >>
> >> And got the following trace:
> >>
> >>
> >> [ 0.115587] Call trace:
> >> [ 0.115686] __filemap_add_folio+0x5dc/0x680 (P)
> >> [ 0.115871] filemap_add_folio+0xec/0x2d0
> >> [ 0.116031] do_read_cache_folio+0x144/0x2d8
> >> [ 0.116194] read_cache_folio+0x1c/0x30
> >> [ 0.116344] read_part_sector+0x4c/0xf0
> >> [ 0.116499] read_lba+0xb0/0x1a0
> >> [ 0.116627] efi_partition+0xa8/0x740
> >> [ 0.116769] bdev_disk_changed+0x238/0x620
> >> [ 0.116939] blkdev_get_whole+0xac/0x100
> >> [ 0.117090] bdev_open+0x280/0x3c0
> >
> > You can't truncate or holepunch a bdev
>
> Yep, I realized that later, thanks : )
>
> Just that the kerneldoc says "Expects mapping->invalidate_lock to be held"
> so was wondering whether this comment is appropriate. Difficult for me to
> reason about that since this goes into fs/block code.
Yes, you've found a documentation bug.
+ BUG_ON(!inode_is_locked(mapping->host) &&
+ !rwsem_is_locked(&mapping->invalidate_lock) &&
+ !S_ISBLK(mapping->host->i_mode));
might do what you're looking for?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [BUG?] invalidate_lock not held in read_cache_folio()
2026-06-08 12:19 ` Matthew Wilcox
2026-06-08 13:29 ` Dev Jain
@ 2026-06-09 11:58 ` Jan Kara
1 sibling, 0 replies; 5+ messages in thread
From: Jan Kara @ 2026-06-09 11:58 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Dev Jain, Jan Kara, linux-mm, David Hildenbrand, Ryan Roberts, LKML
On Mon 08-06-26 13:19:30, Matthew Wilcox wrote:
> On Mon, Jun 08, 2026 at 04:54:51PM +0530, Dev Jain wrote:
> > Hi,
> >
> > My understanding is that there are two ways we are serializing against concurrent
> > addition of a folio into the pagecache (see 730633f0b7f9).
> >
> > The kerneldoc of read_cache_folio() says:
> >
> > "Context: May sleep. Expects mapping->invalidate_lock to be held."
> >
> > I put the following in __filemap_add_folio():
> >
> > + BUG_ON(!inode_is_locked(mapping->host) &&
> > + !rwsem_is_locked(&mapping->invalidate_lock));
> >
> >
> > And got the following trace:
> >
> >
> > [ 0.115587] Call trace:
> > [ 0.115686] __filemap_add_folio+0x5dc/0x680 (P)
> > [ 0.115871] filemap_add_folio+0xec/0x2d0
> > [ 0.116031] do_read_cache_folio+0x144/0x2d8
> > [ 0.116194] read_cache_folio+0x1c/0x30
> > [ 0.116344] read_part_sector+0x4c/0xf0
> > [ 0.116499] read_lba+0xb0/0x1a0
> > [ 0.116627] efi_partition+0xa8/0x740
> > [ 0.116769] bdev_disk_changed+0x238/0x620
> > [ 0.116939] blkdev_get_whole+0xac/0x100
> > [ 0.117090] bdev_open+0x280/0x3c0
>
> You can't truncate or holepunch a bdev
You'd hope so but see blkdev_fallocate(). You can punch out pages in the
middle of the bdev mapping. And the blockdev code actually takes care to
grab invalidate_lock around the punching ops. I'd say that
read_part_sector() should grab invalidate_lock to protect against these
races.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-06-09 11:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-06-08 11:24 [BUG?] invalidate_lock not held in read_cache_folio() Dev Jain
2026-06-08 12:19 ` Matthew Wilcox
2026-06-08 13:29 ` Dev Jain
2026-06-08 14:02 ` Matthew Wilcox
2026-06-09 11:58 ` Jan Kara
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®