Re: [PATCH for-akpm for-6.14-rcX] NFS: fix nfs_release_folio() to not call nfs_wb_folio() from kcompactd

[Mike Snitzer <snitzer@kernel.org>]

On Wed, Feb 26, 2025 at 10:44:15AM -0500, Mike Snitzer wrote:
> On Wed, Feb 26, 2025 at 06:58:11AM -0800, Christoph Hellwig wrote:
> > On Mon, Feb 24, 2025 at 07:33:01PM -0500, Mike Snitzer wrote:
> > > Add PF_KCOMPACTD flag and current_is_kcompactd() helper to check for
> > > it so nfs_release_folio() can skip calling nfs_wb_folio() from
> > > kcompactd.
> > > 
> > > Otherwise NFS can deadlock waiting for kcompactd enduced writeback
> > > which recurses back to NFS (which triggers writeback to NFSD via
> > > NFS loopback mount on the same host, NFSD blocks waiting for XFS's
> > > call to __filemap_get_folio):
> > 
> > Having a flag for a specific kernel thread feels wrong.  I'm not an
> > expert in this area, but as fast as I can tell the problem is that
> > kcompactd should be calling into ->release_folio without __GFP_IO
> > set.
> 
> We can easily remove PF_KCOMPACTD and current_is_kcompactd() if/when
> more analysis and a cleaner fix emerges (from you, mm experts, etc).
> I'm not saying you're wrong about GFP flags needing to be clamped by
> kcompactd's call to ->release_folio, but it seems more finishing work
> needed.
> 
> As you can tell from my patch, we already have kswapd specialization
> with PF_KSWAPD and current_is_kswapd().  A consumer of large folios
> knowing that it being called as kcompactd is useful, hence my fix for
> deadlock seen with NFS loopback mounts on memory constrained systems.

Also, as followup to my fix: Trond and I have started exploring giving
NFS the ability to do more meaningful work on behalf of kswapd and
kcompactd from ->release_folio (rather than simply punt, by returning
false, like your proposed GFP flag clamping would do), see:

https://git.kernel.org/pub/scm/linux/kernel/git/snitzer/linux.git/commit/?h=kernel-6.12/nfs-next&id=b8fd0d3864e4bd43eaca1045002e89bede8fd91f

(I'm still working on testing/refining this patch...)