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: <920c627330f3c7d295ab58edd1b62f28fdbd14bc.camel@surriel.com>
Date:   Thu, 26 Nov 2020 13:04:14 -0500
From:   Rik van Riel <riel@...riel.com>
To:     Michal Hocko <mhocko@...e.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 Thu, 2020-11-26 at 14:40 +0100, Michal Hocko wrote:
> On Tue 24-11-20 14:49:24, 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.
> > 
> > Make sure the gfp mask used to opportunistically allocate a THP
> > is always at least as restrictive as the original gfp mask.
> 
> I have brought this up in the previous version review and I feel my
> feedback hasn't been addressed. Please describe the expected behavior
> by
> those shmem users including GFP_KERNEL restriction which would make
> the
> THP flags incompatible. Is this a problem? Is there any actual
> problem
> if the THP uses its own set of flags?

In the case of i915, the gfp flags passed in by the i915
driver expect the VM to easily fail the allocation, in
which case the i915 driver will reclaim some existing
buffers and try again.

Trying harder than the original gfp_mask would
change
the OOM behavior of systems using the i915 driver.

> I am also not happy how those two sets of flags are completely
> detached
> and we can only expect surprises there. 

I would be more than happy to implement things differently,
but I am not sure what alternative you are suggesting.

-- 
All Rights Reversed.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)