On 4/28/23 05:41, Jan Kara wrote: > If the page is pinned, there's no point in trying to reclaim it. > Furthermore if the page is from the page cache we don't want to reclaim > fs-private data from the page because the pinning process may be writing > to the page at any time and reclaiming fs private info on a dirty page > can upset the filesystem (see link below). > > Link: https://lore.kernel.org/linux-mm/20180103100430.GE4911@xxxxxxxxxxxxxx > Signed-off-by: Jan Kara <jack@xxxxxxx> > --- > mm/vmscan.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > This was the non-controversial part of my series [1] dealing with pinned pages > in filesystems. It is already a win as it avoids crashes in the filesystem and > we can drop workarounds for this in ext4. Can we merge it please? > > [1] https://lore.kernel.org/all/20230209121046.25360-1-jack@xxxxxxx/ > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index bf3eedf0209c..401a379ea99a 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1901,6 +1901,16 @@ static unsigned int shrink_folio_list(struct list_head *folio_list, > } > } > > + /* > + * Folio is unmapped now so it cannot be newly pinned anymore. > + * No point in trying to reclaim folio if it is pinned. > + * Furthermore we don't want to reclaim underlying fs metadata > + * if the folio is pinned and thus potentially modified by the > + * pinning process as that may upset the filesystem. > + */ > + if (folio_maybe_dma_pinned(folio)) > + goto activate_locked; > + This is huge! At long last. In fact, with this in the queue, I'm going to close out our internal bug report from 2018 that launched this whole maybe-dma-pinned odyssey. :) Reviewed-by: John Hubbard <jhubbard@xxxxxxxxxx> thanks, -- John Hubbard NVIDIA > mapping = folio_mapping(folio); > if (folio_test_dirty(folio)) { > /*
