linux-kernel - Re: [PATCH 2/3] mm,thp,shm: limit gfp mask to no more than specified

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]

Message-ID: <20201130100053.GD17338@dhcp22.suse.cz>
Date:   Mon, 30 Nov 2020 11:00:53 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Rik van Riel <riel@...riel.com>
Cc:     hughd@...gle.com, xuyu@...ux.alibaba.com,
        akpm@...ux-foundation.org, mgorman@...e.de, aarcange@...hat.com,
        willy@...radead.org, linux-kernel@...r.kernel.org,
        kernel-team@...com, linux-mm@...ck.org, vbabka@...e.cz
Subject: Re: [PATCH 2/3] mm,thp,shm: limit gfp mask to no more than specified

On Fri 27-11-20 14:03:39, Rik van Riel wrote:
> On Fri, 2020-11-27 at 08:52 +0100, Michal Hocko wrote:
> > On Thu 26-11-20 13:04:14, Rik van Riel wrote:
> > > 
> > > I would be more than happy to implement things differently,
> > > but I am not sure what alternative you are suggesting.
> > 
> > Simply do not alter gfp flags? Or warn in some cases of a serious
> > mismatch.
> > E.g. GFP_ZONEMASK mismatch because there are already GFP_KERNEL users
> > of
> > shmem.
> 
> Not altering the gfp flags is not really an option,
> because that would leads to attempting to allocate THPs
> with GFP_HIGHUSER, which is what is used to allocate
> regular tmpfs pages.

Right but that is a completely different reason to alter the mask and it
would be really great to know whether this is a theoretical concern or
those users simply do not ever use THPs. Btw. should they be using THPs
even if they opt themselves into GFP_KERNEL restriction?
 
> If the THP configuration in sysfs says we should
> not
> be doing compaction/reclaim from THP allocations, we
> should obey that configuration setting, and use a 
> gfp_flags that results in no compaction/reclaim being done.

Yes, I agree with that. The thing I disagree with is that you try to mix
how hard to try also from the shmem users which are not really THP aware
and they merely want to control how hard to try to order-0 pages. Or
more precisely whether to invoke OOM killer before doing their fallback.

So your patch adds a very subtle behavior that would be really hard to
maintain long term because the way how hart to compact is completely
detached from users who use the gfp mask.
-- 
Michal Hocko
SUSE Labs