| Message ID | 20210823124307.970182-1-hch@lst.de (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: unexport folio_add_lru | expand |
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?
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.
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
Only used in core mm code. Signed-off-by: Christoph Hellwig <hch@lst.de> --- mm/swap.c | 1 - 1 file changed, 1 deletion(-)