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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CA+55aFwGpDtMR=8GfDqyZGdw_pQFxG-EL15LaNm0wVoXZChXSA@mail.gmail.com>
Date:	Sun, 20 May 2012 12:03:40 -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 Sat, May 19, 2012 at 7:32 PM, David Rientjes <rientjes@...gle.com> wrote:
>
> Why wasn't this caught by gfp_allowed_mask in slab_pre_alloc_hook()?
> GFP_KERNEL should be allowed in this context.

We set gfp_allowed_mask to allow all allocations before this point: it
happens when we enable interrupts fairly early during start_kernel().

So by the time pidmap_init() is called, GFP_KERNEL does imply that
scheduling can happen.

Which does imply that we set gfp_allowed_mask *much* too early. We
still cannot schedule at that point (well, at least there's a comment
saying so):

        /*
         * Disable preemption - early bootup scheduling is extremely
         * fragile until we cpu_idle() for the first time.
         */
        preempt_disable();

so logically we should move the gfp_allowed_mask setting down to where
we really are properly alive.

How about moving it down to after we've done the full smp_init() and
after we've actually done the first schedule and have proper idle
CPU's?

Something like the attached (UNTESTED!) patch?

                       Linus

Download attachment "patch.diff" of type "application/octet-stream" (742 bytes)