From: Christoph Lameter <clameter@sgi.com>
To: David Miller <davem@davemloft.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SLUB bug on sparc64
Date: Mon, 20 Aug 2007 11:34:52 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0708201124140.25298@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20070817.221758.116352652.davem@davemloft.net>
On Fri, 17 Aug 2007, David Miller wrote:
> When I force SLUB debugging on sparc64, it barfs on early bootup while
> making the sysfs nodes. Removing the BUG()'s on the sysfs error
> returns, and adding some tracing I captured the log below.
>
> BTW, I would recommending removing the BUG() calls, they serve only to
> force someone hitting them to edit them out and reboot which is
> absolutely pointless :-) This code can also often run before the
> console is first enabled, making analysis of the error return that
> much harder if it BUG()'s instead of trying to continue.
Not sure what BUG's you are talking about.
> The problem seems to be that both tsb_512KB and tsb_1MB are
> unmergeable, and so are the kmalloc caches of those sizes. But the
> "unique name" created for the aliases are identical, always ":%d"
> where %d is the cache size, so the kobject_add() fails the second
> time around.
Well it seems that they are both mergeable since slabs larger than 64k *
sizeof(void) are exempt from unmergeable processing and we get into issues
because the merge policy is inconsistent for the larger slabs then.
Does this patch fix it?
Limit the maximum size of merged slab caches
We always switch off the debugging bits of slabs that are too large
for free pointer relocation. This means that we may create separate
caches even if slub_debug is set. Sysfs later thinks they are mergeable
and thus creates unique ids that may then clash.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c 2007-08-20 11:31:13.000000000 -0700
+++ linux-2.6/mm/slub.c 2007-08-20 11:34:12.000000000 -0700
@@ -209,6 +209,7 @@ static inline void ClearSlabDebug(struct
* The page->inuse field is 16 bit thus we have this limitation
*/
#define MAX_OBJECTS_PER_SLAB 65535
+#define MAX_MERGE_SIZE (MAX_OBJECTS_PER_SLAB * sizeof(void))
/* Internal SLUB flags */
#define __OBJECT_POISON 0x80000000 /* Poison object */
@@ -1000,7 +1001,7 @@ static void kmem_cache_open_debug_check(
* Debugging or ctor may create a need to move the free
* pointer. Fail if this happens.
*/
- if (s->objsize >= 65535 * sizeof(void *)) {
+ if (s->objsize >= MAX_MERGE_SIZE) {
BUG_ON(s->flags & (SLAB_RED_ZONE | SLAB_POISON |
SLAB_STORE_USER | SLAB_DESTROY_BY_RCU));
BUG_ON(s->ctor);
@@ -2649,6 +2650,12 @@ static int slab_unmergeable(struct kmem_
if (s->refcount < 0)
return 1;
+ /*
+ * Or a slab that is too large for merging
+ */
+ if (s->size >= MAX_MERGE_SIZE)
+ return 1;
+
return 0;
}
@@ -2668,6 +2675,9 @@ static struct kmem_cache *find_mergeable
align = calculate_alignment(flags, align, size);
size = ALIGN(size, align);
+ if (size >= MAX_MERGE_SIZE)
+ return NULL;
+
list_for_each_entry(s, &slab_caches, list) {
if (slab_unmergeable(s))
continue;
next prev parent reply other threads:[~2007-08-20 18:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-18 5:17 David Miller
2007-08-20 18:34 ` Christoph Lameter [this message]
2007-08-20 23:01 ` David Miller
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=Pine.LNX.4.64.0708201124140.25298@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®