Re: Freeing page flags

[Eric Biggers <ebiggers@kernel.org>]

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