linux-kernel - Re: [PATCH 2/2] 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: <20201119093842.GC12284@dhcp22.suse.cz>
Date:   Thu, 19 Nov 2020 10:38:42 +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,
        Andrey Grodzovsky <andrey.grodzovsky@....com>,
        Chris Wilson <chris@...is-wilson.co.uk>
Subject: Re: [PATCH 2/2] mm,thp,shm: limit gfp mask to no more than specified

On Fri 13-11-20 22:40:40, Rik van Riel wrote:
> On Thu, 2020-11-12 at 12:22 +0100, Michal Hocko wrote:
> > [Cc Chris for i915 and Andray]
> > 
> > On Thu 05-11-20 14:15:08, Rik van Riel wrote:
> > > Matthew Wilcox pointed out that the i915 driver opportunistically
> > > allocates tmpfs memory, but will happily reclaim some of its
> > > pool if no memory is available.
> > 
> > It would be good to explicitly mention the requested gfp flags for
> > those
> > allocations. i915 uses __GFP_NORETRY | __GFP_NOWARN, or GFP_KERNEL.
> > Is
> > __shmem_rw really meant to not allocate from highmeme/movable zones?
> > Can
> > it be ever backed by THPs?
> 
> You are right, I need to copy the zone flags __GFP_DMA
> through
> __GFP_MOVABLE straight from the limiting gfp_mask
> into the gfp_mask used for THP allocations, and not use
> the default THP zone flags if the caller specifies something
> else.
> 
> I'll send out a new version that fixes that.

Can we make one step back here and actually check whether all this is
actually needed for those shmem users before adding more hacks here and
there?
-- 
Michal Hocko
SUSE Labs