>>> It's interesting, that for writeback we never unlock the folio on the I/O >>> path, >>> but instead have the dedicated page flag to tell us when writeback is >>> complete. >> >> PG_locked and PG_writeback are two different lock-bits with two >> different meanings. >> When a folio is PG_locked the content is invalid and shouldn't be accessed. >> When a folio is in PG_writeback its data is not safe even though >> PG_dirty has been cleared (if I remember correctly). >> >> So these are two separate, though related, lock bits that would both >> need to be tracked. lockdep would detect how they are related. > > Some history ... before we had PG_writeback, we held PG_locked > throughout the writeback process. People argued convincingly that it > was fine to map a page into a process's address space (which requires > PG_locked) while it was being written back. And so PG_locked was > split. Now we take PG_locked at the beginning of the writeback process > and downgrade to PG_writeback at some point.
Right, conceptually I would have thought we could do something similar on the readahead path. PG_uptodate is likely not what we want I suspect. Not that such a change would be easy, or that we should do it; just one thing that came to mind. -- Cheers, David
