linux-kernel - Re: [GIT PULL v2] Early SLAB fixes for 2.6.31

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: <1245062727.12400.23.camel@pasglop>
Date:	Mon, 15 Jun 2009 20:45:27 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, cl@...ux-foundation.org,
	kamezawa.hiroyu@...fujitsu.com, lizf@...fujitsu.com, mingo@...e.hu,
	yinghai@...nel.org
Subject: Re: [GIT PULL v2] Early SLAB fixes for 2.6.31

On Mon, 2009-06-15 at 12:27 +0200, Nick Piggin wrote:
> 
> > So from code shuffling point of view, it's better to support
> GFP_KERNEL
> > (almost) everywhere rather than require special annotations.
> 
> Nor this. We require special allocation annotations *everywhere*
> according to context. Why is using GFP_KERNEL for unsleeping
> allocations a good thing if we have GFP_ATOMIC etc?

GFP_ATOMIC is a good point in fact. We -could- make it unnecessary since
we can pretty much tell nowadays whether we are in atomic context or
not.

So where do we put the line ? The subtle differences here are, imho:

 - It's good to discourage allocations in atomic contexts. So requiring
GFP_ATOMIC to some extent helps making people think twice about they are
doing.

 - Code that requires GFP_ATOMIC is generally code that knows pretty
well in which context it's running, because most of the time, it's the
same piece of code or subsystem that is -causing- the context to be
atomic (because it's an interrupt handler or because it used a
spinlock). The case of boot time is subtely different. We have a whole
bunch of things that will be called both at boot time and later, without
necessarily knowing where they have been called from. IE. The call
traces are longer if you want in the typical boot context than in the
typical atomic context.

It all boils down to a fine line to be found here between the two
options, and my gut feeling is that we should keep GFP_ATOMIC explicit,
but avoid the need to provide an explicit API for boot time allocations.

> We could also mask off __GFP_WAIT from allocations when we take
> a spinlock or enter an interrupt, right?

We -could-. Whether we want to is to be debated. Also the overhead of
doing so would be higher I believe.

> Init code doesn't deserve to be more lazy than anybody else, and
> part of the reason why such a core piece of code is so crufty
> is exactly because people have been lazy there.

I think the main problem isn't necessarily init code per se, but the
pile of -common- code that can be called both at init time and later.

Cheers,
Ben.


--
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/