From: Peter Hurley <peter@hurleysoftware.com>
To: Meelis Roos <mroos@linux.ee>
Cc: Christoph Lameter <cl@linux.com>,
Ethan Zhao <ethan.kernel@gmail.com>,
alokk@calsoftinc.com, shobhit@calsoftinc.com,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/slab.c: check pointer slabp before using it in alloc_slabmgmt()
Date: Tue, 10 Dec 2013 11:19:05 -0500 [thread overview]
Message-ID: <52A73EF9.4050105@hurleysoftware.com> (raw)
In-Reply-To: <00000142dd262a23-776dfc34-c3e4-4229-8684-d99131a2f758-000000@email.amazonses.com>
On 12/10/2013 10:35 AM, Christoph Lameter wrote:
> On Tue, 10 Dec 2013, Ethan Zhao wrote:
>
>> No, stable 3.12.4 and 3.12.3 need this patch. 3.13RC doesn't
>> need it anymore.
>
> Hmmm.. Then this commit may have fixed it:
Cross-threaded from [Re: Slab BUG with DEBUG_* options ]
On 12/08/2013 10:00 AM, Meelis Roos wrote:
> ldata alloc change + your second slab patch + slab debug: hang on boot
> after
> console [tty0] enabled, bootconsole disabled
> (after that, I should see all the dmesg again on serial but I do not).
Meelis,
Please grab this patch below and see if it fixes your 'hang on boot'
with Christoph's other slab patch + slab debug.
Regards,
Peter Hurley
> commit 0172f779e4314639a8ed440082cfe9e3450954e8
> Author: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Date: Wed Oct 30 19:04:00 2013 +0900
>
> slab: fix to calm down kmemleak warning
>
> After using struct page as slab management, we should not call
> kmemleak_scan_area(), since struct page isn't the tracking object of
> kmemleak. Without this patch and if CONFIG_DEBUG_KMEMLEAK is enabled,
> so many kmemleak warnings are printed.
>
> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Signed-off-by: Pekka Enberg <penberg@iki.fi>
>
> diff --git a/mm/slab.c b/mm/slab.c
> index af2db76..a8a9349 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -2531,14 +2531,6 @@ static struct freelist *alloc_slabmgmt(struct
> kmem_cache *cachep,
> /* Slab management obj is off-slab. */
> freelist = kmem_cache_alloc_node(cachep->freelist_cache,
> local_flags, nodeid);
> - /*
> - * If the first object in the slab is leaked (it's allocated
> - * but no one has a reference to it), we want to make sure
> - * kmemleak does not treat the ->s_mem pointer as a reference
> - * to the object. Otherwise we will not report the leak.
> - */
> - kmemleak_scan_area(&page->lru, sizeof(struct list_head),
> - local_flags);
> if (!freelist)
> return NULL;
> } else {
>
next prev parent reply other threads:[~2013-12-10 16:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-08 9:38 [PATCH] mm/slab.c: check pointer slabp before using it in alloc_slabmgmt() ethan.zhao
2013-12-09 16:11 ` Christoph Lameter
2013-12-10 7:08 ` Ethan Zhao
2013-12-10 8:16 ` Ethan Zhao
2013-12-10 15:35 ` Christoph Lameter
2013-12-10 16:19 ` Peter Hurley [this message]
2013-12-14 11:15 ` Meelis Roos
2013-12-10 15:40 ` Christoph Lameter
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=52A73EF9.4050105@hurleysoftware.com \
--to=peter@hurleysoftware.com \
--cc=alokk@calsoftinc.com \
--cc=cl@linux.com \
--cc=ethan.kernel@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mroos@linux.ee \
--cc=shobhit@calsoftinc.com \
/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.