linux-kernel - Re: [PATCH] pidmap: Use GFP_ATOMIC to allocate page (was: Re: [ 00/54] 3.0.32-stable review)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 20 May 2012 16:35:57 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] pidmap: Use GFP_ATOMIC to allocate page (was: Re: [
 00/54] 3.0.32-stable review)

On Sun, May 20, 2012 at 4:22 PM, David Rientjes <rientjes@...gle.com> wrote:
>
> I think this may be unnecessarily too late; smp_init() will rely on the
> arch-dependent cpu_up to guarantee that cpu_idle() has been called and
> sched_init_smp() seems to think we can do GFP_KERNEL.

Well, yes, we can pretty much rely on scheduling having to work at the
top of kernel_init(), since kernel_init is being run in a new thread
(and thus must have scheduled from the original thread that becomes
the first idle thread).

But I thought we might as well delay it until the system was really
up, since I wasn't entirely sure what the heck the other CPU's might
be doing. That said, I don't really care deeply, I think that anywhere
in kernel_init should be fine.  I have no strong opinions, but the
current location does seem buggy.

That said, I'm not going to delay 3.4 over this (in fact, I already
tagged it locally, but haven't pushed out yet because the back-end
kernel.org machines seem to be unreachable right now). It apparently
only matters for configurations that are not really all that
realistic.

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