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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 Dec 2021 17:23:40 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Huangzhaoyang <huangzhaoyang@...il.com>
Cc:     Zhaoyang Huang <zhaoyang.huang@...soc.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, linux-cachefs@...hat.com,
        David Howells <dhowells@...hat.com>
Subject: Re: [PATCH] mm: mask DIRECT_RECLAIM in kswapd

On Mon,  6 Dec 2021 11:19:22 +0800 Huangzhaoyang <huangzhaoyang@...il.com> wrote:

> From: Zhaoyang Huang <zhaoyang.huang@...soc.com>
> 
> As the eg bellowing, using GFP_KERNEL could confuse the registered .releasepage
> or .shrinker functions when called in kswapd and have them acting wrongly.Mask
> __GFP_DIRECT_RECLAIM in kswapd.
> 
> eg,
> kswapd
>   shrink_page_list
>     try_to_release_page
>       __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.

> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4083,7 +4083,7 @@ static int balance_pgdat(pg_data_t *pgdat, int order, int highest_zoneidx)
>  	bool boosted;
>  	struct zone *zone;
>  	struct scan_control sc = {
> -		.gfp_mask = GFP_KERNEL,
> +		.gfp_mask = GFP_KERNEL & ~__GFP_DIRECT_RECLAIM,
>  		.order = order,
>  		.may_unmap = 1,
>  	};

Maybe hack the hack like this?

--- a/fs/fscache/page.c~a
+++ a/fs/fscache/page.c
@@ -126,8 +126,10 @@ page_busy:
 	 * sleeping on memory allocation, so we may need to impose a timeout
 	 * too. */
 	if (!(gfp & __GFP_DIRECT_RECLAIM) || !(gfp & __GFP_FS)) {
-		fscache_stat(&fscache_n_store_vmscan_busy);
-		return false;
+		if (!current_is_kswapd()) {
+			fscache_stat(&fscache_n_store_vmscan_busy);
+			return false;
+		}
 	}
 
 	fscache_stat(&fscache_n_store_vmscan_wait);
_

But please, do cc the fscache mailing list and maintainer when mucking
with these things.