Re: [PATCH v2 2/7] doc: Correct the description of ->release_folio

Matthew Wilcox
2023-06-05T13:12:03Z

On Sun, Jun 04, 2023 at 01:33:06PM -0700, Darrick J. Wong wrote:
> On Sun, Jun 04, 2023 at 09:10:55PM +0100, Matthew Wilcox wrote:
> > On Sun, Jun 04, 2023 at 10:55:48AM -0700, Darrick J. Wong wrote:
> > > On Fri, Jun 02, 2023 at 11:24:39PM +0100, Matthew Wilcox (Oracle) wrote:
> > > > -->release_folio() is called when the kernel is about to try to drop the
> > > > -buffers from the folio in preparation for freeing it. It returns false to
> > > > -indicate that the buffers are (or may be) freeable. If ->release_folio is
> > > > -NULL, the kernel assumes that the fs has no private interest in the buffers.
> > > > +->release_folio() is called when the MM wants to make a change to the
> > > > +folio that would invalidate the filesystem's private data. For example,
> > > > +it may be about to be removed from the address_space or split. The folio
> > > > +is locked and not under writeback. It may be dirty. The gfp parameter is
> > > > +not usually used for allocation, but rather to indicate what the filesystem
> > > > +may do to attempt to free the private data. The filesystem may
> > > > +return false to indicate that the folio's private data cannot be freed.
> > > > +If it returns true, it should have already removed the private data from
> > > > +the folio. If a filesystem does not provide a ->release_folio method,
> > > > +the kernel will call try_to_free_buffers().
> > >
> > > the MM? Since you changed that above... :)
> > >
> > > With that nit fixed,
> > > Reviewed-by: Darrick J. Wong <djwong@kernel.org>
> >
> > Well, is it the MM? At this point, the decision is made by
> > filemap_release_folio(), which is the VFS, in my opinion ;-)
>
> It's in mm/filemap.c, which I think makes it squarely the pagecache/mm,
> not the vfs.

Changed this to:

If a filesystem does not provide a ->release_folio method,
the pagecache will assume that private data is buffer_heads and call
try_to_free_buffers().