linux-kernel - Re: [PATCH] slab: remove store

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]

Message-ID: <alpine.DEB.2.21.1904162040570.1780@nanos.tec.linutronix.de>
Date:   Tue, 16 Apr 2019 20:50:22 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Vlastimil Babka <vbabka@...e.cz>
cc:     Qian Cai <cai@....pw>, akpm@...ux-foundation.org, luto@...nel.org,
        jpoimboe@...hat.com, sean.j.christopherson@...el.com,
        penberg@...nel.org, rientjes@...gle.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] slab: remove store_stackinfo()

On Tue, 16 Apr 2019, Vlastimil Babka wrote:

> On 4/16/19 4:22 PM, Qian Cai wrote:
> > store_stackinfo() does not seem used in actual SLAB debugging.
> > Potentially, it could be added to check_poison_obj() to provide more
> > information, but this seems like an overkill due to the declining
> > popularity of the SLAB, so just remove it instead.
> > 
> > Signed-off-by: Qian Cai <cai@....pw>
> 
> I've acked Thomas' version already which was narrower, but no objection
> to remove more stuff on top of that. Linus (and I later in another
> thread) already pointed out /proc/slab_allocators. It only takes a look
> at add_caller() there to not regret removing that one.

The issue why I was looking at this was a krobot complaint about the kernel
crashing in that stack store function with my stackguard series applied. It
was broken before the stackguard pages already, it just went unnoticed.

As you explained, nobody is caring about DEBUG_SLAB + DEBUG_PAGEALLOC
anyway, so I'm happy to not care about krobot tripping over it either.

So we have 3 options:

   1) I ignore it and merge the stack guard series w/o it

   2) I can carry the minimal fix or Qian's version in the stackguard
      branch

   3) We ship that minimal fix to Linus right now and then everyone can
      base their stuff on top independently.

#3 is probably the right thing to do.

Thanks,

	tglx