All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christopher Lameter <cl@linux.com>
To: Miles Chen <miles.chen@mediatek.com>
Cc: Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	wsd_upstream@mediatek.com, linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] slub: Fix sysfs duplicate filename creation when slub_debug=O
Date: Wed, 8 Nov 2017 09:05:12 -0600 (CST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1711080903460.6161@nuc-kabylake> (raw)
In-Reply-To: <1510119138.17435.19.camel@mtkswgap22>

On Wed, 8 Nov 2017, Miles Chen wrote:

> > Ok then the aliasing failed for some reason. The creation of the unique id
> > and the alias detection needs to be in sync otherwise duplicate filenames
> > are created. What is the difference there?
>
> The aliasing failed because find_mergeable() returns if (flags &
> SLAB_NEVER_MERGE) is true. So we do not go to search for alias caches.
>
> __kmem_cache_alias()
>   find_mergeable()
>     kmem_cache_flags()  --> setup flag by the slub_debug
>     if (flags & SLAB_NEVER_MERGE) return NULL;
>     ...
>     search alias logic...
>
>
> The flags maybe changed if disable_higher_order_debug=1. So the
> unmergeable cache becomes mergeable later.

Ok so make sure taht the aliasing logic also clears those flags before
checking for SLAB_NEVER_MERGE.

> > The clearing of the DEBUG_METADATA_FLAGS looks ok to me. kmem_cache_alias
> > should do the same right?
> >
> Yes, I think clearing DEBUG_METADATA flags in kmem_cache_alias is
> another solution for this issue.
>
> We will need to do calculate_sizes() by using original flags and compare
> the order of s->size and s->object_size when
> disable_higher_order_debug=1.

Hmmm... Or move the aliasing check to a point where we know the size of
the slab objects?

WARNING: multiple messages have this Message-ID (diff)
From: Christopher Lameter <cl@linux.com>
To: Miles Chen <miles.chen@mediatek.com>
Cc: Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	wsd_upstream@mediatek.com, linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] slub: Fix sysfs duplicate filename creation when slub_debug=O
Date: Wed, 8 Nov 2017 09:05:12 -0600 (CST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1711080903460.6161@nuc-kabylake> (raw)
In-Reply-To: <1510119138.17435.19.camel@mtkswgap22>

On Wed, 8 Nov 2017, Miles Chen wrote:

> > Ok then the aliasing failed for some reason. The creation of the unique id
> > and the alias detection needs to be in sync otherwise duplicate filenames
> > are created. What is the difference there?
>
> The aliasing failed because find_mergeable() returns if (flags &
> SLAB_NEVER_MERGE) is true. So we do not go to search for alias caches.
>
> __kmem_cache_alias()
>   find_mergeable()
>     kmem_cache_flags()  --> setup flag by the slub_debug
>     if (flags & SLAB_NEVER_MERGE) return NULL;
>     ...
>     search alias logic...
>
>
> The flags maybe changed if disable_higher_order_debug=1. So the
> unmergeable cache becomes mergeable later.

Ok so make sure taht the aliasing logic also clears those flags before
checking for SLAB_NEVER_MERGE.

> > The clearing of the DEBUG_METADATA_FLAGS looks ok to me. kmem_cache_alias
> > should do the same right?
> >
> Yes, I think clearing DEBUG_METADATA flags in kmem_cache_alias is
> another solution for this issue.
>
> We will need to do calculate_sizes() by using original flags and compare
> the order of s->size and s->object_size when
> disable_higher_order_debug=1.

Hmmm... Or move the aliasing check to a point where we know the size of
the slab objects?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2017-11-08 15:05 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-07  3:05 [PATCH] slub: Fix sysfs duplicate filename creation when slub_debug=O miles.chen
2017-11-07  3:05 ` miles.chen
2017-11-07 15:22 ` Christopher Lameter
2017-11-07 15:22   ` Christopher Lameter
2017-11-08  5:32   ` Miles Chen
2017-11-08  5:32     ` Miles Chen
2017-11-08  5:32     ` Miles Chen
2017-11-08 15:05     ` Christopher Lameter [this message]
2017-11-08 15:05       ` Christopher Lameter
2017-11-09  8:52       ` Miles Chen
2017-11-09  8:52         ` Miles Chen
2017-11-09 15:49         ` Christopher Lameter
2017-11-09 15:49           ` Christopher Lameter
2017-11-09 23:51           ` Miles Chen
2017-11-09 23:51             ` Miles Chen
2017-11-10 16:02             ` Christopher Lameter
2017-11-10 16:02               ` Christopher Lameter
2017-11-12  1:40               ` Miles Chen
2017-11-12  1:40                 ` Miles Chen
2017-11-12  1:40                 ` Miles Chen
2017-11-08  3:05 ` kbuild test robot
2017-11-08  3:05   ` kbuild test robot
2017-11-08  3:05   ` kbuild test robot

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.20.1711080903460.6161@nuc-kabylake \
    --to=cl@linux.com \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=miles.chen@mediatek.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=wsd_upstream@mediatek.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.