linux-kernel - Re: [PATCH 1/2] mm,page_alloc: don't call __node_reclaim() without scoped allocation constraints.

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:   Fri, 1 Sep 2017 14:55:24 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, David Rientjes <rientjes@...gle.com>,
        Mel Gorman <mgorman@...e.de>, Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH 1/2] mm,page_alloc: don't call __node_reclaim() without
 scoped allocation constraints.

On Fri 01-09-17 21:40:07, Tetsuo Handa wrote:
> We are doing the first allocation attempt before calling
> current_gfp_context(). But since slab shrinker functions might depend on
> __GFP_FS and/or __GFP_IO masking, calling slab shrinker functions from
> node_reclaim() from get_page_from_freelist() without calling
> current_gfp_context() has possibility of deadlock. Therefore, make sure
> that the first memory allocation attempt does not call slab shrinker
> functions.

But we do filter gfp_mask at __node_reclaim layer. Not really ideal from
the readability point of view and maybe it could be cleaned up there
shouldn't be any bug AFAICS. On the other hand we can save few cycles on
the hot path that way and there are people who care about every cycle
there and node reclaim is absolutely the last thing they care about.
-- 
Michal Hocko
SUSE Labs