diff options
| author |   Christoph Lameter <cl@linux.com> | 2012-09-08 18:27:10 +0000 |
|---|---|---|
| committer |   Pekka Enberg <penberg@kernel.org> | 2012-09-10 09:57:19 +0300 |
| commit | 9df53b154ac712c87db1170057aa6df05eb7bdbd (patch) | |
| tree | 729700a0ed6c05e059946ed5fe174cc005d5da82 /mm/slub.c | |
| parent | Revert "mm/sl[aou]b: Move sysfs_slab_add to common" (diff) | |
| download | linux-dev-9df53b154ac712c87db1170057aa6df05eb7bdbd.tar.xz linux-dev-9df53b154ac712c87db1170057aa6df05eb7bdbd.zip | |
slub: Zero initial memory segment for kmem_cache and kmem_cache_node
Tony Luck reported the following problem on IA-64:
Worked fine yesterday on next-20120905, crashes today. First sign of
trouble was an unaligned access, then a NULL dereference. SL*B related
bits of my config:
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_SLABINFO=y
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
And he console log.
PID hash table entries: 4096 (order: 1, 32768 bytes)
Dentry cache hash table entries: 262144 (order: 7, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 6, 1048576 bytes)
Memory: 2047920k/2086064k available (13992k code, 38144k reserved,
6012k data, 880k init)
kernel unaligned access to 0xca2ffc55fb373e95, ip=0xa0000001001be550
swapper[0]: error during unaligned kernel access
-1 [1]
Modules linked in:
Pid: 0, CPU 0, comm: swapper
psr : 00001010084a2018 ifs : 800000000000060f ip :
[<a0000001001be550>] Not tainted (3.6.0-rc4-zx1-smp-next-20120906)
ip is at new_slab+0x90/0x680
unat: 0000000000000000 pfs : 000000000000060f rsc : 0000000000000003
rnat: 9666960159966a59 bsps: a0000001001441c0 pr : 9666960159965a59
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
csd : 0000000000000000 ssd : 0000000000000000
b0 : a0000001001be500 b6 : a00000010112cb20 b7 : a0000001011660a0
f6 : 0fff7f0f0f0f0e54f0000 f7 : 0ffe8c5c1000000000000
f8 : 1000d8000000000000000 f9 : 100068800000000000000
f10 : 10005f0f0f0f0e54f0000 f11 : 1003e0000000000000078
r1 : a00000010155eef0 r2 : 0000000000000000 r3 : fffffffffffc1638
r8 : e0000040600081b8 r9 : ca2ffc55fb373e95 r10 : 0000000000000000
r11 : e000004040001646 r12 : a000000101287e20 r13 : a000000101280000
r14 : 0000000000004000 r15 : 0000000000000078 r16 : ca2ffc55fb373e75
r17 : e000004040040000 r18 : fffffffffffc1646 r19 : e000004040001646
r20 : fffffffffffc15f8 r21 : 000000000000004d r22 : a00000010132fa68
r23 : 00000000000000ed r24 : 0000000000000000 r25 : 0000000000000000
r26 : 0000000000000001 r27 : a0000001012b8500 r28 : a00000010135f4a0
r29 : 0000000000000000 r30 : 0000000000000000 r31 : 0000000000000001
Unable to handle kernel NULL pointer dereference (address
0000000000000018)
swapper[0]: Oops 11003706212352 [2]
Modules linked in:
Pid: 0, CPU 0, comm: swapper
psr : 0000121008022018 ifs : 800000000000cc18 ip :
[<a0000001004dc8f1>] Not tainted (3.6.0-rc4-zx1-smp-next-20120906)
ip is at __copy_user+0x891/0x960
unat: 0000000000000000 pfs : 0000000000000813 rsc : 0000000000000003
rnat: 0000000000000000 bsps: 0000000000000000 pr : 9666960159961765
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f
csd : 0000000000000000 ssd : 0000000000000000
b0 : a00000010004b550 b6 : a00000010004b740 b7 : a00000010000c750
f6 : 000000000000000000000 f7 : 1003e9e3779b97f4a7c16
f8 : 1003e0a00000010001550 f9 : 100068800000000000000
f10 : 10005f0f0f0f0e54f0000 f11 : 1003e0000000000000078
r1 : a00000010155eef0 r2 : a0000001012870b0 r3 : a0000001012870b8
r8 : 0000000000000298 r9 : 0000000000000013 r10 : 0000000000000000
r11 : 9666960159961a65 r12 : a000000101287010 r13 : a000000101280000
r14 : a000000101287068 r15 : a000000101287080 r16 : 0000000000000298
r17 : 0000000000000010 r18 : 0000000000000018 r19 : a000000101287310
r20 : 0000000000000290 r21 : 0000000000000000 r22 : 0000000000000000
r23 : a000000101386f58 r24 : 0000000000000000 r25 : 000000007fffffff
r26 : a000000101287078 r27 : a0000001013c69b0 r28 : 0000000000000000
r29 : 0000000000000014 r30 : 0000000000000000 r31 : 0000000000000813
Sedat Dilek and Hugh Dickins reported similar problems as well.
Earlier patches in the common set moved the zeroing of the kmem_cache
structure into common code. See "Move allocation of kmem_cache into
common code".
The allocation for the two special structures is still done from SLUB
specific code but no zeroing is done since the cache creation functions
used to zero. This now needs to be updated so that the structures are
zeroed during allocation in kmem_cache_init(). Otherwise random pointer
values may be followed.
Reported-by: Tony Luck <tony.luck@intel.com>
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reported-by: Hugh Dickins <hughd@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
Diffstat (limited to 'mm/slub.c')
| -rw-r--r-- | mm/slub.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/mm/slub.c b/mm/slub.c index dafd465f7a3f..2258ed82880a 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3707,7 +3707,7 @@ void __init kmem_cache_init(void) /* Allocate two kmem_caches from the page allocator */ kmalloc_size = ALIGN(kmem_size, cache_line_size()); order = get_order(2 * kmalloc_size); - kmem_cache = (void *)__get_free_pages(GFP_NOWAIT, order); + kmem_cache = (void *)__get_free_pages(GFP_NOWAIT | __GFP_ZERO, order); /* * Must first have the slab cache available for the allocations of the |