linux-kernel - Re: [RFC PATCH] treewide: remove GFP

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, 25 Aug 2017 09:28:19 +0200
From:   Pavel Machek <pavel@....cz>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     linux-mm@...ck.org, Mel Gorman <mgorman@...e.de>,
        Matthew Wilcox <willy@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>, Neil Brown <neilb@...e.de>,
        Theodore Ts'o <tytso@....edu>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] treewide: remove GFP_TEMPORARY allocation flag

On Fri 2017-08-25 08:35:46, Michal Hocko wrote:
> On Wed 23-08-17 19:57:09, Pavel Machek wrote:
> > Hi!
> > 
> > > From: Michal Hocko <mhocko@...e.com>
> > > 
> > > GFP_TEMPORARY has been introduced by e12ba74d8ff3 ("Group short-lived
> > > and reclaimable kernel allocations") along with __GFP_RECLAIMABLE. It's
> > > primary motivation was to allow users to tell that an allocation is
> > > short lived and so the allocator can try to place such allocations close
> > > together and prevent long term fragmentation. As much as this sounds
> > > like a reasonable semantic it becomes much less clear when to use the
> > > highlevel GFP_TEMPORARY allocation flag. How long is temporary? Can
> > > the context holding that memory sleep? Can it take locks? It seems
> > > there is no good answer for those questions.
> > > 
> > > The current implementation of GFP_TEMPORARY is basically
> > > GFP_KERNEL | __GFP_RECLAIMABLE which in itself is tricky because
> > > basically none of the existing caller provide a way to reclaim the
> > > allocated memory. So this is rather misleading and hard to evaluate for
> > > any benefits.
> > > 
> > > I have checked some random users and none of them has added the flag
> > > with a specific justification. I suspect most of them just copied from
> > > other existing users and others just thought it might be a good idea
> > > to use without any measuring. This suggests that GFP_TEMPORARY just
> > > motivates for cargo cult usage without any reasoning.
> > > 
> > > I believe that our gfp flags are quite complex already and especially
> > > those with highlevel semantic should be clearly defined to prevent from
> > > confusion and abuse. Therefore I propose dropping GFP_TEMPORARY and
> > > replace all existing users to simply use GFP_KERNEL. Please note that
> > > SLAB users with shrinkers will still get __GFP_RECLAIMABLE heuristic
> > > and so they will be placed properly for memory fragmentation prevention.
> > > 
> > > I can see reasons we might want some gfp flag to reflect shorterm
> > > allocations but I propose starting from a clear semantic definition and
> > > only then add users with proper justification.
> > 
> > Dunno. < 1msec probably is temporary, 1 hour probably is not. If it causes
> > problems, can you just #define GFP_TEMPORARY GFP_KERNEL ? Treewide replace,
> > and then starting again goes not look attractive to me.
> 
> I do not think we want a highlevel GFP_TEMPORARY without any meaning.
> This just supports spreading the flag usage without a clear semantic
> and it will lead to even bigger mess. Once we can actually define what
> the flag means we can also add its users based on that new semantic.

It has real meaning.

You can define more exact meaning, and then adjust the usage. But
there's no need to do treewide replacement...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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