[PATCH] mm: unexport folio_add_lru

[PATCH] mm: unexport folio_add_lru

[Christoph Hellwig]

Only used in core mm code.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 mm/swap.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/mm/swap.c b/mm/swap.c
index 04b678342c020..d88895fcd26f8 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -459,7 +459,6 @@ void folio_add_lru(struct folio *folio)
 		__pagevec_lru_add(pvec);
 	local_unlock(&lru_pvecs.lock);
 }
-EXPORT_SYMBOL(folio_add_lru);
 
 /**
  * lru_cache_add_inactive_or_unevictable
-- 
2.30.2

Re: [PATCH] mm: unexport folio_add_lru

[Matthew Wilcox]

On Mon, Aug 23, 2021 at 02:43:07PM +0200, Christoph Hellwig wrote:
> Only used in core mm code.

Yes, but that's going to be true of virtually all the folio symbols
which are wrapped in folio-compat.c.  Perhaps we can give this one a
year to see what the CIFS and FUSE folio conversions end up looking like?

Re: [PATCH] mm: unexport folio_add_lru

[Christoph Hellwig]

On Mon, Aug 23, 2021 at 02:13:00PM +0100, Matthew Wilcox wrote:
> On Mon, Aug 23, 2021 at 02:43:07PM +0200, Christoph Hellwig wrote:
> > Only used in core mm code.
> 
> Yes, but that's going to be true of virtually all the folio symbols
> which are wrapped in folio-compat.c.  Perhaps we can give this one a
> year to see what the CIFS and FUSE folio conversions end up looking like?

A year before exporting something random?  Yes.  CIFS seems to be
mostly related to their strange ->readpages which shouldn't exist
in this form.  Fuse hs some deep mm magic related to
replace_page_cache_page, which should probably deal with the LRU
as well.