All of lore.kernel.org
 help / color / mirror / Atom feed
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
To: Paul Mundt <lethal@linux-sh.org>,
	linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-mm@vger.kernel.org
Subject: Re: [PATCH] slab: fix slab flags for archs use alignment larger 64-bit
Date: Fri, 13 Feb 2009 09:00:30 +0000	[thread overview]
Message-ID: <499544AD.3030804@st.com> (raw)
In-Reply-To: <20090212185640.GA6111@linux-sh.org>

Paul Mundt wrote:
> No, this change in itself is not sufficient. The redzone marker placement
> as well as that of the user store need to know about the minalign as well
> before slab debug can work correctly.
>
> I last looked at this when introducing ARCH_SLAB_MINALIGN:
>
> http://article.gmane.org/gmane.linux.kernel/262528
>
> But it would need some rework for the current slab code.
>
> Note that the ARCH_KMALLOC_MINALIGN value has no meaning here, as this
> relates to slab caches in general, of which kmalloc just happens to have
> a few. This is also why the rest of the kmem_cache_create() code
> references ARCH_SLAB_MINALIGN in the first place. But that in itself is
> irrelevant since for the kmalloc slab caches, ARCH_KMALLOC_MINALIGN is
> already passed in as the align value for kmem_cache_create(), so ralign
> is already set to L1_CACHE_BYTES immediately before that check.
>
> What exactly are you having problems with that made you come up with this
> patch? It would be helpful to know precisely what your issues are, as
> this change in itself is only related to slab debug, and not general
> operation
Thanks for your feedback.

This patch is only to fix the debug information reported in
/proc/slab_allocators .

On SH, I've noticed that /proc/slab_allocators has no size-X entries.
I guess, we should find these fields, shouldn't we?

IIUC, and as you explained above, ralign is already set to the cache
line size by the following code:
...
/* 3) caller mandated alignment */
if (ralign < align)
ralign = align;

Then, there is following check:
...
/* disable debug if necessary */
if (ralign > _alignof__(unsigned long long))
flags &= ~(SLAB_RED_ZONE | SLAB_STORE_USER);

In my point of view, just this check appears "incoherent" (please, note
I'm not familiar with the slab internals).
It always makes sense in case of x86 where ARCH_KMALLOC_MINALIGN is
defined as: __alignof__(unsigned long long) as well.
In case of sh, we always disable debug for 32 aligned objects. As side
effect, within the leaks_show function we immediately exit for them.
Indeed, after applying the patch, I attached, I was able to find size-X
fields within the slab_allocators proc entry.



WARNING: multiple messages have this Message-ID (diff)
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
To: Paul Mundt <lethal@linux-sh.org>,
	linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-mm@vger.kernel.org
Subject: Re: [PATCH] slab: fix slab flags for archs use alignment larger 64-bit
Date: Fri, 13 Feb 2009 11:00:13 +0100	[thread overview]
Message-ID: <499544AD.3030804@st.com> (raw)
In-Reply-To: <20090212185640.GA6111@linux-sh.org>

Paul Mundt wrote:
> No, this change in itself is not sufficient. The redzone marker placement
> as well as that of the user store need to know about the minalign as well
> before slab debug can work correctly.
>
> I last looked at this when introducing ARCH_SLAB_MINALIGN:
>
> http://article.gmane.org/gmane.linux.kernel/262528
>
> But it would need some rework for the current slab code.
>
> Note that the ARCH_KMALLOC_MINALIGN value has no meaning here, as this
> relates to slab caches in general, of which kmalloc just happens to have
> a few. This is also why the rest of the kmem_cache_create() code
> references ARCH_SLAB_MINALIGN in the first place. But that in itself is
> irrelevant since for the kmalloc slab caches, ARCH_KMALLOC_MINALIGN is
> already passed in as the align value for kmem_cache_create(), so ralign
> is already set to L1_CACHE_BYTES immediately before that check.
>
> What exactly are you having problems with that made you come up with this
> patch? It would be helpful to know precisely what your issues are, as
> this change in itself is only related to slab debug, and not general
> operation
Thanks for your feedback.

This patch is only to fix the debug information reported in
/proc/slab_allocators .

On SH, I've noticed that /proc/slab_allocators has no size-X entries.
I guess, we should find these fields, shouldn't we?

IIUC, and as you explained above, ralign is already set to the cache
line size by the following code:
...
/* 3) caller mandated alignment */
if (ralign < align)
ralign = align;

Then, there is following check:
...
/* disable debug if necessary */
if (ralign > _alignof__(unsigned long long))
flags &= ~(SLAB_RED_ZONE | SLAB_STORE_USER);

In my point of view, just this check appears "incoherent" (please, note
I'm not familiar with the slab internals).
It always makes sense in case of x86 where ARCH_KMALLOC_MINALIGN is
defined as: __alignof__(unsigned long long) as well.
In case of sh, we always disable debug for 32 aligned objects. As side
effect, within the leaks_show function we immediately exit for them.
Indeed, after applying the patch, I attached, I was able to find size-X
fields within the slab_allocators proc entry.



  reply	other threads:[~2009-02-13  9:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-12 17:51 [PATCH] slab: fix slab flags for archs use alignment larger 64-bit Giuseppe CAVALLARO
2009-02-12 18:56 ` Paul Mundt
2009-02-12 18:56   ` Paul Mundt
2009-02-13  9:00   ` Giuseppe CAVALLARO [this message]
2009-02-13 10:00     ` Giuseppe CAVALLARO
2009-02-13  9:22     ` [PATCH] slab: fix slab flags for archs use alignment larger Pekka Enberg
2009-02-13  9:22       ` [PATCH] slab: fix slab flags for archs use alignment larger 64-bit Pekka Enberg
2009-02-13  9:30       ` [PATCH] slab: fix slab flags for archs use alignment larger Pekka Enberg
2009-02-13  9:30         ` [PATCH] slab: fix slab flags for archs use alignment larger 64-bit Pekka Enberg
2009-02-13  9:30         ` Pekka Enberg
2009-02-13  9:47       ` [PATCH] slab: fix slab flags for archs use alignment larger Giuseppe CAVALLARO
2009-02-13 10:46         ` [PATCH] slab: fix slab flags for archs use alignment larger 64-bit Giuseppe CAVALLARO
2009-02-13 10:05         ` [PATCH] slab: fix slab flags for archs use alignment larger Pekka Enberg
2009-02-13 10:05           ` [PATCH] slab: fix slab flags for archs use alignment larger 64-bit Pekka Enberg
2009-02-13 10:16           ` [PATCH] slab: fix slab flags for archs use alignment larger Giuseppe CAVALLARO
2009-02-13 11:15             ` [PATCH] slab: fix slab flags for archs use alignment larger 64-bit Giuseppe CAVALLARO
2009-02-13 13:11             ` [PATCH] slab: fix slab flags for archs use alignment larger Giuseppe CAVALLARO
2009-02-13 14:11               ` [PATCH] slab: fix slab flags for archs use alignment larger 64-bit Giuseppe CAVALLARO
2009-02-13 13:41               ` [PATCH] slab: fix slab flags for archs use alignment larger Pekka Enberg
2009-02-13 13:41                 ` [PATCH] slab: fix slab flags for archs use alignment larger 64-bit Pekka Enberg
2009-02-18  8:31                 ` [PATCH] slab: fix slab flags for archs use alignment larger Giuseppe CAVALLARO
2009-02-18  9:30                   ` [PATCH] slab: fix slab flags for archs use alignment larger 64-bit Giuseppe CAVALLARO
  -- strict thread matches above, loose matches on Subject: below --
2009-02-12 16:53 Giuseppe CAVALLARO
2009-02-12 17:47 ` Giuseppe CAVALLARO

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=499544AD.3030804@st.com \
    --to=peppe.cavallaro@st.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@vger.kernel.org \
    --cc=linux-sh@vger.kernel.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.