All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vandrovec <vandrove@vc.cvut.cz>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: BUG at mm/slab.c:662 - current 2.6.13-git (commit 87fc...) crashes on x86-64
Date: Sun, 11 Sep 2005 15:22:44 +0200	[thread overview]
Message-ID: <43242FA4.9010303@vc.cvut.cz> (raw)
In-Reply-To: <Pine.LNX.4.62.0509101948230.20145@schroedinger.engr.sgi.com>

Christoph Lameter wrote:
> On Sat, 10 Sep 2005, Petr Vandrovec wrote:
> 
> 
>>Christoph Lameter wrote:
>>
>>>Actually the kernel configuration you mentioned (SMP with K8 NUMA support
>>>booted on single processor) was the primary development platform for the
>>>patch. 
>>>CONFIG_DEBUG_SLAB=y
>>
>>Strange...  I had to apply patch below - after doing that everything seems to
>>be happy and running.  Though it is not right fix, it seems to work fine
>>here...
> 
> 
> Hmmm. That is strange indeed and would mean that one of the initial caches 
> has not correctly been initialized or we are using a smaller cache size 
> than the management caches. With your patch the system fell 
> back to a larger size slab (which seems to be present). Weird.
> 
> What is your setting for L1_CACHE_BYTES?

64.  Well, at least CONFIG_X86_L1_CACHE_BYTES has this value.  Last few lines in 
/proc/slabinfo in reverse order are:

kmem_cache
size-64
size-128
size-32
size-32(DMA)
size-64(DMA)
size-128(DMA)

so 64 (INDEX_AC) & 128 (INDEX_L3) slabs were created first.  But 
__find_general_cachep BUGs on *first* entry, which is 32 byte one on systems 
with 4KB pages.

It seems to me that problem is CONFIG_DEBUG_SLAB together with 
CONFIG_DEBUG_SPINLOCK and/or CONFIG_PREEMPT - in your configuration spinlock_t 
has 4 bytes, and whole arraycache_init 32 bytes - so it fits into size-32 slab, 
and you do not hit BUG that size-32 slab does not exist.

On SMP systems with CONFIG_DEBUG_SPINLOCK or CONFIG_PREEMPT spinlock_t is 8 
bytes, and so arraycache_init has 36 bytes, and it no longer fits into 
size-32...  And if you'll enable both SPINLOCK debugging and PREEMPT, you get 12 
bytes spinlock_t and 40 byte arraycache_init...

So I believe that if you'll rebuild your kernel with PREEMPT or DEBUG_SPINLOCK 
(or both), you'll get crash I'm seeing.  Probably size-32 slab needs to be 
special cased same way INDEX_AC and INDEX_L3 arrays are.
								Petr Vandrovec


      reply	other threads:[~2005-09-11 13:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-10 13:26 BUG at mm/slab.c:662 - current 2.6.13-git (commit 87fc...) crashes on x86-64 Petr Vandrovec
2005-09-10 17:30 ` Christoph Lameter
2005-09-10 19:05   ` Petr Vandrovec
2005-09-11  3:01     ` Christoph Lameter
2005-09-11 13:22       ` Petr Vandrovec [this message]

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=43242FA4.9010303@vc.cvut.cz \
    --to=vandrove@vc.cvut.cz \
    --cc=clameter@engr.sgi.com \
    --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 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.