All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Thomas Gleixner <tglx@linutronix.de>
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 23:19:11 +0200	[thread overview]
Message-ID: <235d7500-8235-c7d4-0d6f-4d069133bd8d@suse.cz> (raw)
In-Reply-To: <alpine.DEB.2.21.1904162040570.1780@nanos.tec.linutronix.de>

On 4/16/2019 8:50 PM, Thomas Gleixner wrote:
> 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.

I think #3 is overkill for something that was broken for who knows how long and
nobody noticed. I'd go with 2) and perhaps Qian's version as nobody AFAIK uses
the caller+cpu as well as the stack trace.

For Qian's version also:
Acked-by: Vlastimil Babka <vbabka@suse.cz>

> #3 is probably the right thing to do.
> 
> Thanks,
> 
> 	tglx
> 


  reply	other threads:[~2019-04-16 21:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-16 14:22 [PATCH] slab: remove store_stackinfo() Qian Cai
2019-04-16 15:25 ` Vlastimil Babka
2019-04-16 15:34   ` Qian Cai
2019-04-16 18:50   ` Thomas Gleixner
2019-04-16 18:50     ` Thomas Gleixner
2019-04-16 21:19     ` Vlastimil Babka [this message]
2019-04-16 21:21       ` Thomas Gleixner
2019-04-16 21:21         ` Thomas Gleixner
2019-04-17  9:36 ` 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=235d7500-8235-c7d4-0d6f-4d069133bd8d@suse.cz \
    --to=vbabka@suse.cz \
    --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=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.