On Tue 02-05-23 13:20:20, Andrew Morton wrote: > On Fri, 28 Apr 2023 14:41:40 +0200 Jan Kara <jack@xxxxxxx> 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). > > Obviously I'll add a cc:stable here. I'm suspecting it's so old that > there's no real Fixes: target that makes sense? In principle the problem is there ever since MM started to track dirty shared pages and filesystems started to use .page_mkwrite callbacks. So for very long, yes. That being said the fix makes sense only since we've added page pinning infrastructure and started using it in various places which is not that long ago (in 2020, first patches in this direction have been merged to 5.7). So we could mark it for stable with 5.7+. > > --- 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; > > + > > So I expect the -stable maintainers will be looking for a pre-folios > version of this when the time comes. Yeah, right. Luckily that's going to be pretty easy :). Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
