linux-kernel - Re: [PATCH trivial] block: GFP_ATOMIC is __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]

Message-ID: <20080629171528.5590b78b@linux360.ro>
Date:	Sun, 29 Jun 2008 17:15:28 +0300
From:	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
To:	Hugh Dickins <hugh@...itas.com>
Cc:	Jens Axboe <jens.axboe@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH trivial] block: GFP_ATOMIC is __GFP_HIGH

On Sun, 29 Jun 2008 07:16:49 +0100 (BST)
Hugh Dickins <hugh@...itas.com> wrote:

> but it is not
> accidental that GFP_ATOMIC includes __GFP_HIGH - it's precisely when
> we're atomic that we need access to those extra reserves; and where
> we don't actually want them then we do say GFP_NOWAIT not GFP_ATOMIC.

I would expect GFP_ATOMIC just prevents sleeping, while it _could_ fail
(in theory) unless it is allowed to touch the emergency pools.

Actually, in many/most atomic contexts bail-out paths are possible for
allocation failures. And many/most of these atomic contexts have no
special reason to require emergency memory. Think about the usual
allocations enclosed within spinlocks.

> I expect the gfp flags will change in the future; but unless I missed
> somewhere, amongst all the places which specify GFP_ATOMIC throughout
> the kernel, this is the only one which ors in __GFP_HIGH too.  I don't
> believe it expected access to extra extra reserves!  So I thought we'd
> do best to remove the anomaly.

Yes, it seems this is the only place where this occurs.

Although I did not read all the code and resolved its implications, it
seems like it actually needs something like __GFP_NOFAIL (?) instead of
__GFP_HIGH. The slab itself is created with SLAB_PANIC.

> (But what I'd actually intended to grep for was __GFP_HIGHMEM.)
> 
> Hugh

	Eduard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/