linux-kernel - Re: [PATCH] mm: mask DIRECT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2502103.1638956412@warthog.procyon.org.uk>
Date:   Wed, 08 Dec 2021 09:40:12 +0000
From:   David Howells <dhowells@...hat.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     dhowells@...hat.com, Huangzhaoyang <huangzhaoyang@...il.com>,
        Zhaoyang Huang <zhaoyang.huang@...soc.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, linux-cachefs@...hat.com
Subject: Re: [PATCH] mm: mask DIRECT_RECLAIM in kswapd

Andrew Morton <akpm@...ux-foundation.org> wrote:

> >       __fscache_maybe_release_page
> > 	...
> >          if (!(gfp & __GFP_DIRECT_RECLAIM) || !(gfp & __GFP_FS)) {
> >                  fscache_stat(&fscache_n_store_vmscan_busy);
> >                  return false;
> >          }
> 
> Well, we have thus far been permitting kswapd's memory allocations to
> enter direct reclaim.  Forbidding that kernel-wide might be the right
> thing to do, or might not be.  But disabling it kernel-wide because of
> a peculiar hack in fscache is not good justification.

It's avoiding sleeping in ->releasepage() if fscache is doing something with
the page.  With the old I/O still used by nfs and cifs, PG_fscache means that
the page is known to fscache and it might be doing something with it in the
background.  You have to ask fscache to release the page, which may require
I/O to take place, to get rid of the mark.

With the new I/O, as used by 9p, afs and ceph, where we're doing async DIO
between the page and the cache, PG_fscache just means that there's a DIO write
in progress from the page.  It will be cleared when the DIO completes.

I'm fine with changing the condition in the if-statement.  Note that in my
fscache-rewrite branch:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=fscache-rewrite

I've been changing this to:

	if (!gfpflags_allow_blocking(gfp) || !(gfp & __GFP_FS))

and the old I/O is gone.  This is aimed at the next merge window.  If you want
me to change it there, let me know.

David