All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: lkp@lists.01.org
Subject: Re: [mm/slub] 555b8c8cb3: WARNING:at_lib/stackdepot.c:#stack_depot_fetch
Date: Mon, 04 Apr 2022 10:10:03 +0200	[thread overview]
Message-ID: <Ykqn2z9UVfxFwiU+@elver.google.com> (raw)
In-Reply-To: <YkpgjgM/aSXd29uj@hyeyoo>

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

On Mon, Apr 04, 2022 at 12:05PM +0900, Hyeonggon Yoo wrote:
> On Sat, Apr 02, 2022 at 12:50:14AM +0900, Hyeonggon Yoo wrote:
> > On Thu, Mar 24, 2022 at 09:52:18AM +0000, Hyeonggon Yoo wrote:
> > > On Wed, Mar 23, 2022 at 05:05:20PM +0800, kernel test robot wrote:
> > > > 
> > > > 
> > > > Greeting,
> > > > 
> > > > FYI, we noticed the following commit (built with gcc-9):
> > > > 
> > > > commit: 555b8c8cb3f335ec8fd9d1ffd25e1395790d102d ("mm/slub: use stackdepot to save stack trace in objects")
> > > > https://git.kernel.org/cgit/linux/kernel/git/vbabka/linux.git slub-stackdepot-v3r1
> > > > 
> > > > in testcase: rcutorture
> > > > version: 
> > > > with following parameters:
> > > > 
> > > > 	runtime: 300s
> > > > 	test: cpuhotplug
> > > > 	torture_type: tasks
> > > > 
> > > 
> > > [+Cc Vlastimil, linux-mm, and people related to stackdepot]
> > > 
> > > I'm going to spend time on it.
> > > I have no clue why this happened yet.
> > >
> > 
> > I modified alloc/free debug processing to check if handle is valid, but
> > it couldn't detect something wrong. Everything was fine when allocating/freeing objects.
> > 
> > Handles must be modified outside SLUB code.
> > (Or maybe SLUB code related to cpu hotplugging did cause this.)
> > 
> > I reproduced this problem on x86_64 with KASAN enabled, but KASAN
> > detects nothing.
> > 
> > I suspect this would be memory corruption bug, race condition, or
> > wrong calculation of object metadata offset. But still have no clue.
> > 
> > I'm going to check if KCSAN detects something.
> > 
> 
> KCSAN also didn't help.

(Maybe CONFIG_KCSAN_STRICT=y is going to yield something? I still doubt
it thought, this bug is related to corrupted stackdepot handle
somewhere...)

> I noticed that it is not reproduced when KASAN=y and KFENCE=n (reproduced 0 of 181).
> and it was reproduced 56 of 196 when KASAN=n and KFENCE=y
> 
> maybe this issue is related to kfence?

What about KASAN=n and KFENCE=n?

Thanks,
-- Marco

WARNING: multiple messages have this Message-ID (diff)
From: Marco Elver <elver@google.com>
To: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: kernel test robot <oliver.sang@intel.com>,
	Oliver Glitta <glittao@gmail.com>,
	lkp@lists.01.org, lkp@intel.com,
	LKML <linux-kernel@vger.kernel.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Imran Khan <imran.f.khan@oracle.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Zhen Lei <thunder.leizhen@huawei.com>,
	Zqiang <qiang.zhang@windriver.com>,
	linux-mm@kvack.org
Subject: Re: [mm/slub]  555b8c8cb3: WARNING:at_lib/stackdepot.c:#stack_depot_fetch
Date: Mon, 4 Apr 2022 10:10:03 +0200	[thread overview]
Message-ID: <Ykqn2z9UVfxFwiU+@elver.google.com> (raw)
In-Reply-To: <YkpgjgM/aSXd29uj@hyeyoo>

On Mon, Apr 04, 2022 at 12:05PM +0900, Hyeonggon Yoo wrote:
> On Sat, Apr 02, 2022 at 12:50:14AM +0900, Hyeonggon Yoo wrote:
> > On Thu, Mar 24, 2022 at 09:52:18AM +0000, Hyeonggon Yoo wrote:
> > > On Wed, Mar 23, 2022 at 05:05:20PM +0800, kernel test robot wrote:
> > > > 
> > > > 
> > > > Greeting,
> > > > 
> > > > FYI, we noticed the following commit (built with gcc-9):
> > > > 
> > > > commit: 555b8c8cb3f335ec8fd9d1ffd25e1395790d102d ("mm/slub: use stackdepot to save stack trace in objects")
> > > > https://git.kernel.org/cgit/linux/kernel/git/vbabka/linux.git slub-stackdepot-v3r1
> > > > 
> > > > in testcase: rcutorture
> > > > version: 
> > > > with following parameters:
> > > > 
> > > > 	runtime: 300s
> > > > 	test: cpuhotplug
> > > > 	torture_type: tasks
> > > > 
> > > 
> > > [+Cc Vlastimil, linux-mm, and people related to stackdepot]
> > > 
> > > I'm going to spend time on it.
> > > I have no clue why this happened yet.
> > >
> > 
> > I modified alloc/free debug processing to check if handle is valid, but
> > it couldn't detect something wrong. Everything was fine when allocating/freeing objects.
> > 
> > Handles must be modified outside SLUB code.
> > (Or maybe SLUB code related to cpu hotplugging did cause this.)
> > 
> > I reproduced this problem on x86_64 with KASAN enabled, but KASAN
> > detects nothing.
> > 
> > I suspect this would be memory corruption bug, race condition, or
> > wrong calculation of object metadata offset. But still have no clue.
> > 
> > I'm going to check if KCSAN detects something.
> > 
> 
> KCSAN also didn't help.

(Maybe CONFIG_KCSAN_STRICT=y is going to yield something? I still doubt
it thought, this bug is related to corrupted stackdepot handle
somewhere...)

> I noticed that it is not reproduced when KASAN=y and KFENCE=n (reproduced 0 of 181).
> and it was reproduced 56 of 196 when KASAN=n and KFENCE=y
> 
> maybe this issue is related to kfence?

What about KASAN=n and KFENCE=n?

Thanks,
-- Marco


  reply	other threads:[~2022-04-04  8:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-23  9:05 [mm/slub] 555b8c8cb3: WARNING:at_lib/stackdepot.c:#stack_depot_fetch kernel test robot
2022-03-24  9:52 ` Hyeonggon Yoo
2022-04-01 15:50   ` Hyeonggon Yoo
2022-04-04  3:05     ` Hyeonggon Yoo
2022-04-04  3:05       ` Hyeonggon Yoo
2022-04-04  8:10       ` Marco Elver [this message]
2022-04-04  8:10         ` Marco Elver
2022-04-04 14:20         ` Vlastimil Babka
2022-04-04 14:20           ` Vlastimil Babka
2022-04-04 15:18           ` Marco Elver
2022-04-04 15:18             ` Marco Elver
2022-04-05  2:00             ` Hyeonggon Yoo
2022-04-05  2:00               ` Hyeonggon Yoo
2022-04-05 11:07               ` Marco Elver
2022-04-05 11:07                 ` Marco Elver
2022-04-05 22:47                 ` Hyeonggon Yoo
2022-04-05 22:47                   ` Hyeonggon Yoo
2022-04-06  8:34                   ` Marco Elver
2022-04-06  8:34                     ` Marco Elver
2022-04-06 11:50                     ` Hyeonggon Yoo
2022-04-06 11:50                       ` Hyeonggon Yoo
2022-04-06 12:15                       ` Marco Elver
2022-04-06 12:15                         ` Marco Elver
2022-04-06 12:31                         ` Hyeonggon Yoo
2022-04-06 12:31                           ` Hyeonggon Yoo

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=Ykqn2z9UVfxFwiU+@elver.google.com \
    --to=elver@google.com \
    --cc=lkp@lists.01.org \
    /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.