linux-kernel - Re: [PATCH v3 0/2] Ajust lockdep static allocations for sparc

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]

Date:   Tue, 29 Nov 2016 13:29:07 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Babu Moger <babu.moger@...cle.com>, Ingo Molnar <mingo@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Tejun Heo <tj@...nel.org>, Sam Ravnborg <sam@...nborg.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        sparclinux <sparclinux@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH v3 0/2] Ajust lockdep static allocations for sparc

On Tue, Nov 29, 2016 at 12:52:04PM +0100, Geert Uytterhoeven wrote:
> > Nah, users don't need more senseless options. This is really only useful
> > for dinky platforms or platforms with limited static image size (like
> > sparc64).
> >
> > If you make this user selectable, someone will do, and then an endless
> > stream of table not big enough warnings will be posted.
> >
> > Also, its only 4MB (IIRC), so who cares.
> 
> I care :-)
> 
> Not because of platforms with not limited memory, but because of platforms
> with boot loaders that have silly kernel size limitations, and start
> scribbling over the DTB or even theirselves when copying a large kernel image.

Right, that's the weird platforms clause above, and those can select the
option.

> BTW, is there any particular reason these huge arrays are in BSS, and not
> allocated dynamically? That would solve my problems as well...

Is there a memory allocator available before _any_ locks are used, and
that itself also doesn't use locks?