[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BC43A3C.7010603@cs.helsinki.fi>
Date: Tue, 13 Apr 2010 12:32:44 +0300
From: Pekka Enberg <penberg@...helsinki.fi>
To: TAO HU <tghk48@...orola.com>, Nick Piggin <npiggin@...e.de>
CC: linux-kernel@...r.kernel.org, cl@...ux-foundation.org,
mpm@...enic.com, linux-mm@...ck.org, dwmw2@...radead.org,
TAO HU <taohu@...orola.com>,
ShiYong LI <shi-yong.li@...orola.com>,
david.rientjes@...gle.com
Subject: Re: [PATCH - V2] Fix missing of last user while dumping slab corruption
log
TAO HU kirjoitti:
> Actually we greped "kmem_cache_create" in whole kernel souce tree
> (2.6.29 and 2.6.32).
>
> Either "align" equal to "0" or flag SLAB_HWCACHE_ALIGN is used when
> calling kmem_cache_create().
I don't think that's correct. The "task_xstate" has alignof(struct
task_xstate) and there seems to be so GCC attributes that force
non-default alignment on the struct.
> Seems all of arch's cache-line-size is multiple of 64-bit/8-byte
> (sizeof(long long)) except arch-microblaze (4-byte).
> The smallest (except arch-microblaze) cache-line-size is 2^4= 16-byte
> as I can see.
> So even considering possible sizeof(long long) == 128-bit/16-byte, it
> is still safe to apply Shiyong's original version.
>
> Anyway, Shiyong's new patch check the weired situation that "align >
> sizeof(long long) && align is NOT multiple of sizeof (long long)"
> Let us know whether the new version address your concerns.
Yeah, sorry for dragging this issue on. I've been looking at the patch
but haven't been able to convince myself that it's correct. Nick, David,
Christoph, Matt, could you also please take a look at this?
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists