Lisa Wang <[email protected]> writes: > To align with the definition of MF_DELAYED, update > shmem_error_remove_folio() to return MF_DELAYED. > > shmem handles memory failures but defers the actual file truncation. The > function's return value should therefore be MF_DELAYED to accurately > reflect the state. > > Currently, this logical error does not cause a bug, because: > > - For shmem folios, folio->private is not set. > - As a result, filemap_release_folio() is a no-op and returns true. > - This, in turn, causes truncate_error_folio() to incorrectly return > MF_RECOVERED. > - The caller then treats MF_RECOVERED as a success condition, masking the > issue. > > The previous patch relays MF_DELAYED to the caller of > truncate_error_folio() before any logging, so returning MF_DELAYED from > shmem_error_remove_folio() will retain the original behavior of not > adding any logs. > > The return value of truncate_error_folio() is consumed in action_result(), > which treats MF_DELAYED the same way as MF_RECOVERED, hence action_result() > also returns the same thing after this change. >
Thanks for explaining here! Reviewed-by: Ackerley Tng <[email protected]> > Signed-off-by: Lisa Wang <[email protected]> > --- > mm/shmem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > > [...snip...] >
