From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
To: Dave Jones <davej@redhat.com>, Christoph Lameter <cl@linux.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Pekka Enberg <penberg@kernel.org>,
linux-mm@kvack.org, David Rientjes <rientjes@google.com>,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: oops in slab/leaks_show
Date: Tue, 11 Mar 2014 17:30:09 +0900 [thread overview]
Message-ID: <20140311083009.GA32004@lge.com> (raw)
In-Reply-To: <20140311025811.GA601@lge.com>
On Tue, Mar 11, 2014 at 11:58:11AM +0900, Joonsoo Kim wrote:
> On Mon, Mar 10, 2014 at 09:24:55PM -0400, Dave Jones wrote:
> > On Tue, Mar 11, 2014 at 10:01:35AM +0900, Joonsoo Kim wrote:
> > > On Tue, Mar 11, 2014 at 09:35:00AM +0900, Joonsoo Kim wrote:
> > > > On Fri, Mar 07, 2014 at 11:18:30AM -0600, Christoph Lameter wrote:
> > > > > Joonsoo recently changed the handling of the freelist in SLAB. CCing him.
> > > > >
> > > > > > I pretty much always use SLUB for my fuzzing boxes, but thought I'd give SLAB a try
> > > > > > for a change.. It blew up when something tried to read /proc/slab_allocators
> > > > > > (Just cat it, and you should see the oops below)
> > > >
> > > > Hello, Dave.
> > > >
> > > > Today, I did a test on v3.13 which contains all my changes on the handling of
> > > > the freelist in SLAB and couldn't trigger oops by just 'cat /proc/slab_allocators'.
> > > >
> > > > So I look at the code and find that there is race window if there is multiple users
> > > > doing 'cat /proc/slab_allocators'. Did your test do that?
> > >
> > > Opps, sorry. I am misunderstanding something. Maybe there is no race.
> > > Anyway, How do you test it?
> >
> > 1. build kernel with CONFIG_SLAB=y.
> > 2. boot kernel
> > 3. cat /proc/slab_allocators
>
> Okay. I reproduce it with CONFIG_DEBUG_PAGEALLOC=y.
>
> I look at the code and find that the problem doesn't come from my patches.
> I think that it is long-lived bug. Let me explain it.
>
> 'cat /proc/slab_allocators' checks all allocated objects for all slabs.
> The problem is that it considers objects in cpu slab caches as allocated objects.
> These objects in cpu slab caches are unmapped if CONFIG_DEBUG_PAGEALLOC=y, so when we
> try to access it to get the caller information, oops would be triggered.
>
> I will think more deeply how to fix this problem.
> If I am missing something, please let me know.
Here is the fix for this problem.
Thanks for reporting it.
---------8<---------------------
next prev parent reply other threads:[~2014-03-11 8:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 2:57 oops in slab/leaks_show Dave Jones
2014-03-07 17:18 ` Christoph Lameter
2014-03-11 0:35 ` Joonsoo Kim
2014-03-11 0:39 ` Dave Jones
2014-03-11 1:01 ` Joonsoo Kim
2014-03-11 1:24 ` Dave Jones
2014-03-11 2:58 ` Joonsoo Kim
2014-03-11 8:30 ` Joonsoo Kim [this message]
2014-04-11 7:36 ` Pekka Enberg
2014-04-16 0:07 ` Joonsoo Kim
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=20140311083009.GA32004@lge.com \
--to=iamjoonsoo.kim@lge.com \
--cc=cl@linux.com \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).