linux-kernel - Re: Linux 2.6.35.2

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: <AANLkTingwMvoVm_J6cmm_K3=G9rCYwOrQ=-5vK_wzGcX@mail.gmail.com>
Date:	Sat, 14 Aug 2010 11:47:45 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ed Tomlinson <edt@....ca>
Cc:	sedat.dilek@...il.com, Greg KH <gregkh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>, penberg@...nel.org,
	arthur@....ro, wylda@...ny.cz
Subject: Re: Linux 2.6.35.2

On Sat, Aug 14, 2010 at 11:27 AM, Ed Tomlinson <edt@....ca> wrote:
>
> It seems to be helping here.  Without it 35.2 would either stall in boot or give lots of tracebacks.  With it things
> start normally and my background stuff works as expected.

Ok, thanks. I've committed it to the -git tree.

Just to verify: you have CONFIG_HIGHPTE enabled on a x86-32 kernel,
right? I'd have expected this to not ever show up anywhere else, and
I'm just verifying that there isn't anything else going on. I'm
appending the commit message, the patch hasn't changed.

                            Linus
---

Author: Linus Torvalds <torvalds@...ux-foundation.org>
Date:   Sat Aug 14 11:44:56 2010 -0700

    mm: fix page table unmap for stack guard page properly

    We do in fact need to unmap the page table _before_ doing the whole
    stack guard page logic, because if it is needed (mainly 32-bit x86 with
    PAE and CONFIG_HIGHPTE, but other architectures may use it too) then it
    will do a kmap_atomic/kunmap_atomic.

    And those kmaps will create an atomic region that we cannot do
    allocations in.  However, the whole stack expand code will need to do
    anon_vma_prepare() and vma_lock_anon_vma() and they cannot do that in an
    atomic region.

    Now, a better model might actually be to do the anon_vma_prepare() when
    _creating_ a VM_GROWSDOWN segment, and not have to worry about any of
    this at page fault time.  But in the meantime, this is the
    straightforward fix for the issue.

    See https://bugzilla.kernel.org/show_bug.cgi?id=16588 for details.

    Reported-by: Wylda <wylda@...ny.cz>
    Reported-by: Sedat Dilek <sedat.dilek@...il.com>
    Reported-by: Mike Pagano <mpagano@...too.org>
    Reported-by: François Valenduc <francois.valenduc@...ablenet.be>
    Tested-by: Ed Tomlinson <edt@....ca>
    Cc: Pekka Enberg <penberg@...nel.org>
    Cc: Greg KH <gregkh@...e.de>
    Cc: stable@...nel.org
    Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>

 mm/memory.c |   13 ++++++-------
 1 files changed, 6 insertions(+), 7 deletions(-)
--
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/