From: Thomas Gleixner <tglx@linutronix.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Qian Cai <cai@lca.pw>,
akpm@linux-foundation.org, luto@kernel.org, jpoimboe@redhat.com,
sean.j.christopherson@intel.com, penberg@kernel.org,
rientjes@google.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] slab: remove store_stackinfo()
Date: Tue, 16 Apr 2019 20:50:22 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.21.1904162040570.1780@nanos.tec.linutronix.de> (raw)
In-Reply-To: <902fed9c-9655-a241-677d-5fa11b6c95a1@suse.cz>
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@lca.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
next prev parent reply other threads:[~2019-04-16 18:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-16 14:22 Qian Cai
2019-04-16 15:25 ` Vlastimil Babka
2019-04-16 15:34 ` Qian Cai
2019-04-16 18:50 ` Thomas Gleixner [this message]
2019-04-16 21:19 ` Vlastimil Babka
2019-04-16 21:21 ` Thomas Gleixner
2019-04-17 9:36 ` Thomas Gleixner
2019-04-17 14:01 ` [tip:x86/irq] mm/slab: Remove store_stackinfo() tip-bot for Qian Cai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.1904162040570.1780@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=cai@lca.pw \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=sean.j.christopherson@intel.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox