Generalize extra_pins handling to all MF_DELAYED cases not only shmem_mapping.
If MF_DELAYED is returned, the filemap continues to hold refcounts on the folio. Hence, take that into account when checking for extra refcounts. As clarified in an earlier patch, a return value of MF_DELAYED implies that the page still has elevated refcounts. Hence, set extra_pins to true if the return value is MF_DELAYED. This is aligned with the implementation in me_swapcache_dirty(), where, if a folio is still in the swap cache, ret is set to MF_DELAYED and extra_pins is set to true. Signed-off-by: Lisa Wang <[email protected]> --- mm/memory-failure.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 57f7762e7418..86b6f7ba5d3a 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1052,18 +1052,14 @@ static int me_pagecache_clean(struct page_state *ps, struct page *p) goto out; } - /* - * The shmem page is kept in page cache instead of truncating - * so is expected to have an extra refcount after error-handling. - */ - extra_pins = shmem_mapping(mapping); - /* * Truncation is a bit tricky. Enable it per file system for now. * * Open: to take i_rwsem or not for this? Right now we don't. */ ret = truncate_error_folio(folio, page_to_pfn(p), mapping); + + extra_pins = ret == MF_DELAYED; if (has_extra_refcount(ps, p, extra_pins)) ret = MF_FAILED; -- 2.53.0.959.g497ff81fa9-goog
