On Thu, May 12, 2022 at 09:54:59PM +0100, Matthew Wilcox wrote: > The LWN writeup [1] on merging the MGLRU reminded me that I need to send > out a plan for removing page flags that we can do without. > > 1. PG_error. It's basically useless. If the page was read successfully, > PG_uptodate is set. If not, PG_uptodate is clear. The page cache > doesn't use PG_error. Some filesystems do, and we need to transition > them away from using it. One of the uses of PG_error is in ext4 and f2fs to keep track of decryption (fscrypt) and verity (fs-verity) failures on pages in a bio being read. Decryption and verity happen in separate phases, so PG_error is used to record which subset of pages a decryption error occurred on. Similarly, PG_error is also used to record which subset of pages a verity error occurred on, which the filesystem uses to decide whether to set PG_uptodate afterwards. If we had to get rid of it, one idea would be: * Don't keep track of decryption failures on a per-page basis; just fail the whole bio if one occurs. That's how the block layer works, after all; you just get one ->bi_status and not an individual status for each page. Also, decryption failures never really happen in practice anyway. * Also merge together the verity step and the setting-uptodate+unlocking step, so that PG_error isn't needed to propagate the page status between these. This should work since verity only happens at the end anyway. I was also thinking about just unlocking pages as errors occur on them. I think that wouldn't work, because the filesystem wouldn't be able to distinguish between pages it still has locked and pages that got re-locked by someone else. - Eric
