Messages in this thread | | | From | Linus Torvalds <> | Date | Fri, 10 Jun 2022 16:27:24 -0700 | Subject | Re: [GIT PULL] Folio fixes for 5.19 |
| |
On Fri, Jun 10, 2022 at 2:40 PM Matthew Wilcox <willy@infradead.org> wrote: > > But I don't want to change the refcounting rules on a method without > changing something else about the method, because trying to find a > missing refcount change is misery. Anyway, my cunning thought was > that if I bundle the change to the refcount rule with the change > from readahead_page() to readahead_folio(), once all filesystems > are converted to readahead_folio(), I can pull the refcount game out > of readahead_folio() and do it in the caller where it belongs, all > transparent to the filesystems.
Hmm. Any reason why that can't be done right now? Aren't we basically converted already?
Yeah, yeah, there's a couple of users of readahead_page() left, but if cleaning up the folio case requires some fixup to those, then that sounds better than the current "folio interface is very messy".
> (I don't think the erofs code has a bug because it doesn't remove > the folio from the pagecache while holding the lock -- the folio lock > prevents anyone _else_ from removing the folio from the pagecache, > so there must be a reference on the folio up until erofs calls > folio_unlock()).
Ahh. Ugh. And I guess the whole "clearing the lock bit is the last time we touch the page flags" and "folio_wake_bit() is very careful to only touch the external waitqueue" so that there can be no nasty races with somebody coming in *exactly* as the folio is unlocked.
This has been subtle before, but I think we did allow it exactly for this kind of reason. I've swapped out the details.
Linus
| |