Re: slab: odd BUG on kzalloc
On Tue, Feb 19, 2013 at 01:18:25PM -0500, Sasha Levin wrote:
> >> [ 169.930103] ---[ end trace 4d135f3def21b4bd ]---
> >>
> >> The code translates to the following in fs/pipe.c:alloc_pipe_info :
> >>
> >> pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL);
> >> if (pipe) {
> >> pipe->bufs = kzalloc(sizeof(struct pipe_buffer) *
> >> PIPE_DEF_BUFFERS, GFP_KERNEL); <=== this
> >> if (pipe->bufs) {
> >> init_waitqueue_head(>wait);
>
> Looks like it's not specific to pipe(). I've also got this one now:
>
> Since I've managed to reproduce it, I'll go ahead and add slub_debug and see
> what it tells us.
I'm curious, did you recently upgrade gcc, or other parts of the toolchain ?
This, and one of the other 'weird' bugs you reported recently have me wondering
if perhaps you're seeing a compiler bug.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: slab: odd BUG on kzalloc
On 02/19/2013 01:29 PM, Dave Jones wrote:
> On Tue, Feb 19, 2013 at 01:18:25PM -0500, Sasha Levin wrote:
>
> > >> [ 169.930103] ---[ end trace 4d135f3def21b4bd ]---
> > >>
> > >> The code translates to the following in fs/pipe.c:alloc_pipe_info :
> > >>
> > >> pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL);
> > >> if (pipe) {
> > >> pipe->bufs = kzalloc(sizeof(struct pipe_buffer) *
> PIPE_DEF_BUFFERS, GFP_KERNEL); <=== this
> > >> if (pipe->bufs) {
> > >> init_waitqueue_head(>wait);
> >
> > Looks like it's not specific to pipe(). I've also got this one now:
> >
> > Since I've managed to reproduce it, I'll go ahead and add slub_debug and
> see what it tells us.
>
> I'm curious, did you recently upgrade gcc, or other parts of the toolchain ?
> This, and one of the other 'weird' bugs you reported recently have me
> wondering
> if perhaps you're seeing a compiler bug.
It happened once on a kernel built on my gentoo box with is generally up to
date,
but the other time the kernel was built on my mini-server running ubuntu, which
isn't updated that often.
So I don't think compiler trickery is involved.
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: slab: odd BUG on kzalloc
On 02/18/2013 07:35 PM, Christoph Lameter wrote:
> Maybe the result of free pointer corruption due to writing to an object
> after free. Please run again with slub_debug specified on the commandline
> to get detailed reports on how this came about.
>
> On Sun, 17 Feb 2013, Sasha Levin wrote:
>
>> Hi all,
>>
>> I was fuzzing with trinity inside a KVM tools guest, running latest -next
>> kernel,
>> and hit the following bug:
>>
>> [ 169.773688] BUG: unable to handle kernel NULL pointer dereference at
>> 0001
>> [ 169.774976] IP: [] memset+0x1f/0xb0
>> [ 169.775989] PGD 93e02067 PUD ac1a2067 PMD 0
>> [ 169.776898] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>> [ 169.777923] Dumping ftrace buffer:
>> [ 169.778595](ftrace buffer empty)
>> [ 169.779352] Modules linked in:
>> [ 169.779996] CPU 0
>> [ 169.780031] Pid: 13438, comm: trinity Tainted: GW
>> 3.8.0-rc7-next-20130215-sasha-3-gea816fa #286
>> [ 169.780031] RIP: 0010:[] []
>> memset+0x1f/0xb0
>> [ 169.780031] RSP: 0018:8800aef19e00 EFLAGS: 00010206
>> [ 169.780031] RAX: RBX: RCX:
>> 0080
>> [ 169.780031] RDX: RSI: RDI:
>> 0001
>> [ 169.780031] RBP: 8800aef19e68 R08: R09:
>> 0001
>> [ 169.780031] R10: 0001 R11: R12:
>> 8800bb001b00
>> [ 169.780031] R13: 8800bb001b00 R14: 0001 R15:
>> 00537000
>> [ 169.780031] FS: 7fb73581b700() GS:8800bb60()
>> knlGS:
>> [ 169.780031] CS: 0010 DS: ES: CR0: 80050033
>> [ 169.780031] CR2: 0001 CR3: aed31000 CR4:
>> 000406f0
>> [ 169.780031] DR0: DR1: DR2:
>>
>> [ 169.780031] DR3: DR6: 0ff0 DR7:
>> 0400
>> [ 169.780031] Process trinity (pid: 13438, threadinfo 8800aef18000,
>> task 8800aed7b000)
>> [ 169.780031] Stack:
>> [ 169.780031] 81269586 8800aef19e38 0280
>> 81291a2e
>> [ 169.780031] 80d0aa39d9e8 8800aef19e48
>> 8800aa39d9e8
>> [ 169.780031] 8800a65cc780 8800aa39d960 ffea
>>
>> [ 169.780031] Call Trace:
>> [ 169.780031] [] ? kmem_cache_alloc_trace+0x176/0x330
>> [ 169.780031] [] ? alloc_pipe_info+0x3e/0xa0
>> [ 169.780031] [] alloc_pipe_info+0x3e/0xa0
>> [ 169.780031] [] get_pipe_inode+0x36/0xe0
>> [ 169.780031] [] create_pipe_files+0x23/0x140
>> [ 169.780031] [] __do_pipe_flags+0x3d/0xe0
>> [ 169.780031] [] sys_pipe2+0x1b/0xa0
>> [ 169.780031] [] ? tracesys+0x7e/0xe6
>> [ 169.780031] [] sys_pipe+0xb/0x10
>> [ 169.780031] [] tracesys+0xe1/0xe6
>> [ 169.780031] Code: 1e 44 88 1f c3 90 90 90 90 90 90 90 49 89 f9 48 89 d1
>> 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01
>> 01 01 01 48 0f af c6 48 ab 89 d1 f3 aa 4c 89 c8 c3 66 66 66 90 66 66 66
>> 90 66 66
>> [ 169.780031] RIP [] memset+0x1f/0xb0
>> [ 169.780031] RSP
>> [ 169.780031] CR2: 0001
>> [ 169.930103] ---[ end trace 4d135f3def21b4bd ]---
>>
>> The code translates to the following in fs/pipe.c:alloc_pipe_info :
>>
>> pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL);
>> if (pipe) {
>> pipe->bufs = kzalloc(sizeof(struct pipe_buffer) *
>> PIPE_DEF_BUFFERS, GFP_KERNEL); <=== this
>> if (pipe->bufs) {
>> init_waitqueue_head(>wait);
>>
>>
>> Thanks,
>> Sasha
>>
Looks like it's not specific to pipe(). I've also got this one now:
[ 351.807837] BUG: unable to handle kernel NULL pointer dereference at
0001
[ 351.807846] IP: [] memset+0x1f/0xb0
[ 351.807851] PGD a3562067 PUD a2f4e067 PMD 0
[ 351.807856] Oops: 0002 [#2] PREEMPT SMP DEBUG_PAGEALLOC
[ 351.807871] Modules linked in:
[ 351.807877] CPU 0
[ 351.807878] Pid: 27224, comm: trinity Tainted: G D W
3.8.0-rc7-next-20130219-sasha-00030-gc37ee25 #4
[ 351.807883] RIP: 0010:[] []
memset+0x1f/0xb0
[ 351.807885] RSP: 0018:8800b06abea0 EFLAGS: 00010206
[ 351.807887] RAX: RBX: RCX: 0080
[ 351.807889] RDX: RSI: RDI: 0001
[ 351.807890] RBP: 8800b06abf08 R08: 001da950 R09: 0001
[ 351.807892] R10: 00d14000 R11: R12: 0001
[ 351.807893] R13: 80d0 R14: 8800bb001b00 R15: 0320
[ 351.807896] FS: 7fa640100700() GS:8800bb60()
knlGS:
[ 351.807898] CS: 0010 DS: ES: CR0: 80050033
[ 351.807900] CR2: 0001 CR3: a4c68000 CR4: 000406f0
[ 351.807911] DR0: DR1: DR2:
[ 351.807918] DR3: DR6: 0ff0
Re: slab: odd BUG on kzalloc
On 02/18/2013 07:35 PM, Christoph Lameter wrote:
Maybe the result of free pointer corruption due to writing to an object
after free. Please run again with slub_debug specified on the commandline
to get detailed reports on how this came about.
On Sun, 17 Feb 2013, Sasha Levin wrote:
Hi all,
I was fuzzing with trinity inside a KVM tools guest, running latest -next
kernel,
and hit the following bug:
[ 169.773688] BUG: unable to handle kernel NULL pointer dereference at
0001
[ 169.774976] IP: [81a15c2f] memset+0x1f/0xb0
[ 169.775989] PGD 93e02067 PUD ac1a2067 PMD 0
[ 169.776898] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 169.777923] Dumping ftrace buffer:
[ 169.778595](ftrace buffer empty)
[ 169.779352] Modules linked in:
[ 169.779996] CPU 0
[ 169.780031] Pid: 13438, comm: trinity Tainted: GW
3.8.0-rc7-next-20130215-sasha-3-gea816fa #286
[ 169.780031] RIP: 0010:[81a15c2f] [81a15c2f]
memset+0x1f/0xb0
[ 169.780031] RSP: 0018:8800aef19e00 EFLAGS: 00010206
[ 169.780031] RAX: RBX: RCX:
0080
[ 169.780031] RDX: RSI: RDI:
0001
[ 169.780031] RBP: 8800aef19e68 R08: R09:
0001
[ 169.780031] R10: 0001 R11: R12:
8800bb001b00
[ 169.780031] R13: 8800bb001b00 R14: 0001 R15:
00537000
[ 169.780031] FS: 7fb73581b700() GS:8800bb60()
knlGS:
[ 169.780031] CS: 0010 DS: ES: CR0: 80050033
[ 169.780031] CR2: 0001 CR3: aed31000 CR4:
000406f0
[ 169.780031] DR0: DR1: DR2:
[ 169.780031] DR3: DR6: 0ff0 DR7:
0400
[ 169.780031] Process trinity (pid: 13438, threadinfo 8800aef18000,
task 8800aed7b000)
[ 169.780031] Stack:
[ 169.780031] 81269586 8800aef19e38 0280
81291a2e
[ 169.780031] 80d0aa39d9e8 8800aef19e48
8800aa39d9e8
[ 169.780031] 8800a65cc780 8800aa39d960 ffea
[ 169.780031] Call Trace:
[ 169.780031] [81269586] ? kmem_cache_alloc_trace+0x176/0x330
[ 169.780031] [81291a2e] ? alloc_pipe_info+0x3e/0xa0
[ 169.780031] [81291a2e] alloc_pipe_info+0x3e/0xa0
[ 169.780031] [81291ac6] get_pipe_inode+0x36/0xe0
[ 169.780031] [81291d63] create_pipe_files+0x23/0x140
[ 169.780031] [81291ebd] __do_pipe_flags+0x3d/0xe0
[ 169.780031] [81291fbb] sys_pipe2+0x1b/0xa0
[ 169.780031] [83d96135] ? tracesys+0x7e/0xe6
[ 169.780031] [8129204b] sys_pipe+0xb/0x10
[ 169.780031] [83d96198] tracesys+0xe1/0xe6
[ 169.780031] Code: 1e 44 88 1f c3 90 90 90 90 90 90 90 49 89 f9 48 89 d1
83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01
01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 66 66 66 90 66 66 66
90 66 66
[ 169.780031] RIP [81a15c2f] memset+0x1f/0xb0
[ 169.780031] RSP 8800aef19e00
[ 169.780031] CR2: 0001
[ 169.930103] ---[ end trace 4d135f3def21b4bd ]---
The code translates to the following in fs/pipe.c:alloc_pipe_info :
pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL);
if (pipe) {
pipe-bufs = kzalloc(sizeof(struct pipe_buffer) *
PIPE_DEF_BUFFERS, GFP_KERNEL); === this
if (pipe-bufs) {
init_waitqueue_head(pipe-wait);
Thanks,
Sasha
Looks like it's not specific to pipe(). I've also got this one now:
[ 351.807837] BUG: unable to handle kernel NULL pointer dereference at
0001
[ 351.807846] IP: [81a2e8cf] memset+0x1f/0xb0
[ 351.807851] PGD a3562067 PUD a2f4e067 PMD 0
[ 351.807856] Oops: 0002 [#2] PREEMPT SMP DEBUG_PAGEALLOC
[ 351.807871] Modules linked in:
[ 351.807877] CPU 0
[ 351.807878] Pid: 27224, comm: trinity Tainted: G D W
3.8.0-rc7-next-20130219-sasha-00030-gc37ee25 #4
[ 351.807883] RIP: 0010:[81a2e8cf] [81a2e8cf]
memset+0x1f/0xb0
[ 351.807885] RSP: 0018:8800b06abea0 EFLAGS: 00010206
[ 351.807887] RAX: RBX: RCX: 0080
[ 351.807889] RDX: RSI: RDI: 0001
[ 351.807890] RBP: 8800b06abf08 R08: 001da950 R09: 0001
[ 351.807892] R10: 00d14000 R11: R12: 0001
[ 351.807893] R13: 80d0 R14: 8800bb001b00 R15: 0320
[ 351.807896] FS: 7fa640100700() GS:8800bb60()
knlGS:
[ 351.807898] CS: 0010 DS: ES: CR0: 80050033
[ 351.807900] CR2: 0001 CR3: a4c68000 CR4: 000406f0
[ 351.807911]
Re: slab: odd BUG on kzalloc
On 02/19/2013 01:29 PM, Dave Jones wrote:
On Tue, Feb 19, 2013 at 01:18:25PM -0500, Sasha Levin wrote:
[ 169.930103] ---[ end trace 4d135f3def21b4bd ]---
The code translates to the following in fs/pipe.c:alloc_pipe_info :
pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL);
if (pipe) {
pipe-bufs = kzalloc(sizeof(struct pipe_buffer) *
PIPE_DEF_BUFFERS, GFP_KERNEL); === this
if (pipe-bufs) {
init_waitqueue_head(pipe-wait);
Looks like it's not specific to pipe(). I've also got this one now:
Since I've managed to reproduce it, I'll go ahead and add slub_debug and
see what it tells us.
I'm curious, did you recently upgrade gcc, or other parts of the toolchain ?
This, and one of the other 'weird' bugs you reported recently have me
wondering
if perhaps you're seeing a compiler bug.
It happened once on a kernel built on my gentoo box with is generally up to
date,
but the other time the kernel was built on my mini-server running ubuntu, which
isn't updated that often.
So I don't think compiler trickery is involved.
Thanks,
Sasha
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: slab: odd BUG on kzalloc
On Tue, Feb 19, 2013 at 01:18:25PM -0500, Sasha Levin wrote:
[ 169.930103] ---[ end trace 4d135f3def21b4bd ]---
The code translates to the following in fs/pipe.c:alloc_pipe_info :
pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL);
if (pipe) {
pipe-bufs = kzalloc(sizeof(struct pipe_buffer) *
PIPE_DEF_BUFFERS, GFP_KERNEL); === this
if (pipe-bufs) {
init_waitqueue_head(pipe-wait);
Looks like it's not specific to pipe(). I've also got this one now:
Since I've managed to reproduce it, I'll go ahead and add slub_debug and see
what it tells us.
I'm curious, did you recently upgrade gcc, or other parts of the toolchain ?
This, and one of the other 'weird' bugs you reported recently have me wondering
if perhaps you're seeing a compiler bug.
Dave
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: slab: odd BUG on kzalloc
Maybe the result of free pointer corruption due to writing to an object
after free. Please run again with slub_debug specified on the commandline
to get detailed reports on how this came about.
On Sun, 17 Feb 2013, Sasha Levin wrote:
> Hi all,
>
> I was fuzzing with trinity inside a KVM tools guest, running latest -next
> kernel,
> and hit the following bug:
>
> [ 169.773688] BUG: unable to handle kernel NULL pointer dereference at
> 0001
> [ 169.774976] IP: [] memset+0x1f/0xb0
> [ 169.775989] PGD 93e02067 PUD ac1a2067 PMD 0
> [ 169.776898] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> [ 169.777923] Dumping ftrace buffer:
> [ 169.778595](ftrace buffer empty)
> [ 169.779352] Modules linked in:
> [ 169.779996] CPU 0
> [ 169.780031] Pid: 13438, comm: trinity Tainted: GW
> 3.8.0-rc7-next-20130215-sasha-3-gea816fa #286
> [ 169.780031] RIP: 0010:[] []
> memset+0x1f/0xb0
> [ 169.780031] RSP: 0018:8800aef19e00 EFLAGS: 00010206
> [ 169.780031] RAX: RBX: RCX:
> 0080
> [ 169.780031] RDX: RSI: RDI:
> 0001
> [ 169.780031] RBP: 8800aef19e68 R08: R09:
> 0001
> [ 169.780031] R10: 0001 R11: R12:
> 8800bb001b00
> [ 169.780031] R13: 8800bb001b00 R14: 0001 R15:
> 00537000
> [ 169.780031] FS: 7fb73581b700() GS:8800bb60()
> knlGS:
> [ 169.780031] CS: 0010 DS: ES: CR0: 80050033
> [ 169.780031] CR2: 0001 CR3: aed31000 CR4:
> 000406f0
> [ 169.780031] DR0: DR1: DR2:
>
> [ 169.780031] DR3: DR6: 0ff0 DR7:
> 0400
> [ 169.780031] Process trinity (pid: 13438, threadinfo 8800aef18000, task
> 8800aed7b000)
> [ 169.780031] Stack:
> [ 169.780031] 81269586 8800aef19e38 0280
> 81291a2e
> [ 169.780031] 80d0aa39d9e8 8800aef19e48
> 8800aa39d9e8
> [ 169.780031] 8800a65cc780 8800aa39d960 ffea
>
> [ 169.780031] Call Trace:
> [ 169.780031] [] ? kmem_cache_alloc_trace+0x176/0x330
> [ 169.780031] [] ? alloc_pipe_info+0x3e/0xa0
> [ 169.780031] [] alloc_pipe_info+0x3e/0xa0
> [ 169.780031] [] get_pipe_inode+0x36/0xe0
> [ 169.780031] [] create_pipe_files+0x23/0x140
> [ 169.780031] [] __do_pipe_flags+0x3d/0xe0
> [ 169.780031] [] sys_pipe2+0x1b/0xa0
> [ 169.780031] [] ? tracesys+0x7e/0xe6
> [ 169.780031] [] sys_pipe+0xb/0x10
> [ 169.780031] [] tracesys+0xe1/0xe6
> [ 169.780031] Code: 1e 44 88 1f c3 90 90 90 90 90 90 90 49 89 f9 48 89 d1 83
> e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01
> 01 01 01 48 0f af c6 48 ab 89 d1 f3 aa 4c 89 c8 c3 66 66 66 90 66 66 66
> 90 66 66
> [ 169.780031] RIP [] memset+0x1f/0xb0
> [ 169.780031] RSP
> [ 169.780031] CR2: 0001
> [ 169.930103] ---[ end trace 4d135f3def21b4bd ]---
>
> The code translates to the following in fs/pipe.c:alloc_pipe_info :
>
> pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL);
> if (pipe) {
> pipe->bufs = kzalloc(sizeof(struct pipe_buffer) *
> PIPE_DEF_BUFFERS, GFP_KERNEL); <=== this
> if (pipe->bufs) {
> init_waitqueue_head(>wait);
>
>
> Thanks,
> Sasha
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: slab: odd BUG on kzalloc
Maybe the result of free pointer corruption due to writing to an object
after free. Please run again with slub_debug specified on the commandline
to get detailed reports on how this came about.
On Sun, 17 Feb 2013, Sasha Levin wrote:
Hi all,
I was fuzzing with trinity inside a KVM tools guest, running latest -next
kernel,
and hit the following bug:
[ 169.773688] BUG: unable to handle kernel NULL pointer dereference at
0001
[ 169.774976] IP: [81a15c2f] memset+0x1f/0xb0
[ 169.775989] PGD 93e02067 PUD ac1a2067 PMD 0
[ 169.776898] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 169.777923] Dumping ftrace buffer:
[ 169.778595](ftrace buffer empty)
[ 169.779352] Modules linked in:
[ 169.779996] CPU 0
[ 169.780031] Pid: 13438, comm: trinity Tainted: GW
3.8.0-rc7-next-20130215-sasha-3-gea816fa #286
[ 169.780031] RIP: 0010:[81a15c2f] [81a15c2f]
memset+0x1f/0xb0
[ 169.780031] RSP: 0018:8800aef19e00 EFLAGS: 00010206
[ 169.780031] RAX: RBX: RCX:
0080
[ 169.780031] RDX: RSI: RDI:
0001
[ 169.780031] RBP: 8800aef19e68 R08: R09:
0001
[ 169.780031] R10: 0001 R11: R12:
8800bb001b00
[ 169.780031] R13: 8800bb001b00 R14: 0001 R15:
00537000
[ 169.780031] FS: 7fb73581b700() GS:8800bb60()
knlGS:
[ 169.780031] CS: 0010 DS: ES: CR0: 80050033
[ 169.780031] CR2: 0001 CR3: aed31000 CR4:
000406f0
[ 169.780031] DR0: DR1: DR2:
[ 169.780031] DR3: DR6: 0ff0 DR7:
0400
[ 169.780031] Process trinity (pid: 13438, threadinfo 8800aef18000, task
8800aed7b000)
[ 169.780031] Stack:
[ 169.780031] 81269586 8800aef19e38 0280
81291a2e
[ 169.780031] 80d0aa39d9e8 8800aef19e48
8800aa39d9e8
[ 169.780031] 8800a65cc780 8800aa39d960 ffea
[ 169.780031] Call Trace:
[ 169.780031] [81269586] ? kmem_cache_alloc_trace+0x176/0x330
[ 169.780031] [81291a2e] ? alloc_pipe_info+0x3e/0xa0
[ 169.780031] [81291a2e] alloc_pipe_info+0x3e/0xa0
[ 169.780031] [81291ac6] get_pipe_inode+0x36/0xe0
[ 169.780031] [81291d63] create_pipe_files+0x23/0x140
[ 169.780031] [81291ebd] __do_pipe_flags+0x3d/0xe0
[ 169.780031] [81291fbb] sys_pipe2+0x1b/0xa0
[ 169.780031] [83d96135] ? tracesys+0x7e/0xe6
[ 169.780031] [8129204b] sys_pipe+0xb/0x10
[ 169.780031] [83d96198] tracesys+0xe1/0xe6
[ 169.780031] Code: 1e 44 88 1f c3 90 90 90 90 90 90 90 49 89 f9 48 89 d1 83
e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01
01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 66 66 66 90 66 66 66
90 66 66
[ 169.780031] RIP [81a15c2f] memset+0x1f/0xb0
[ 169.780031] RSP 8800aef19e00
[ 169.780031] CR2: 0001
[ 169.930103] ---[ end trace 4d135f3def21b4bd ]---
The code translates to the following in fs/pipe.c:alloc_pipe_info :
pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL);
if (pipe) {
pipe-bufs = kzalloc(sizeof(struct pipe_buffer) *
PIPE_DEF_BUFFERS, GFP_KERNEL); === this
if (pipe-bufs) {
init_waitqueue_head(pipe-wait);
Thanks,
Sasha
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
slab: odd BUG on kzalloc
Hi all,
I was fuzzing with trinity inside a KVM tools guest, running latest -next
kernel,
and hit the following bug:
[ 169.773688] BUG: unable to handle kernel NULL pointer dereference at
0001
[ 169.774976] IP: [] memset+0x1f/0xb0
[ 169.775989] PGD 93e02067 PUD ac1a2067 PMD 0
[ 169.776898] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 169.777923] Dumping ftrace buffer:
[ 169.778595](ftrace buffer empty)
[ 169.779352] Modules linked in:
[ 169.779996] CPU 0
[ 169.780031] Pid: 13438, comm: trinity Tainted: GW
3.8.0-rc7-next-20130215-sasha-3-gea816fa #286
[ 169.780031] RIP: 0010:[] []
memset+0x1f/0xb0
[ 169.780031] RSP: 0018:8800aef19e00 EFLAGS: 00010206
[ 169.780031] RAX: RBX: RCX: 0080
[ 169.780031] RDX: RSI: RDI: 0001
[ 169.780031] RBP: 8800aef19e68 R08: R09: 0001
[ 169.780031] R10: 0001 R11: R12: 8800bb001b00
[ 169.780031] R13: 8800bb001b00 R14: 0001 R15: 00537000
[ 169.780031] FS: 7fb73581b700() GS:8800bb60()
knlGS:
[ 169.780031] CS: 0010 DS: ES: CR0: 80050033
[ 169.780031] CR2: 0001 CR3: aed31000 CR4: 000406f0
[ 169.780031] DR0: DR1: DR2:
[ 169.780031] DR3: DR6: 0ff0 DR7: 0400
[ 169.780031] Process trinity (pid: 13438, threadinfo 8800aef18000, task
8800aed7b000)
[ 169.780031] Stack:
[ 169.780031] 81269586 8800aef19e38 0280
81291a2e
[ 169.780031] 80d0aa39d9e8 8800aef19e48
8800aa39d9e8
[ 169.780031] 8800a65cc780 8800aa39d960 ffea
[ 169.780031] Call Trace:
[ 169.780031] [] ? kmem_cache_alloc_trace+0x176/0x330
[ 169.780031] [] ? alloc_pipe_info+0x3e/0xa0
[ 169.780031] [] alloc_pipe_info+0x3e/0xa0
[ 169.780031] [] get_pipe_inode+0x36/0xe0
[ 169.780031] [] create_pipe_files+0x23/0x140
[ 169.780031] [] __do_pipe_flags+0x3d/0xe0
[ 169.780031] [] sys_pipe2+0x1b/0xa0
[ 169.780031] [] ? tracesys+0x7e/0xe6
[ 169.780031] [] sys_pipe+0xb/0x10
[ 169.780031] [] tracesys+0xe1/0xe6
[ 169.780031] Code: 1e 44 88 1f c3 90 90 90 90 90 90 90 49 89 f9 48 89 d1 83
e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01
01 01 01 48 0f af c6 48 ab 89 d1 f3 aa 4c 89 c8 c3 66 66 66 90 66 66 66 90
66 66
[ 169.780031] RIP [] memset+0x1f/0xb0
[ 169.780031] RSP
[ 169.780031] CR2: 0001
[ 169.930103] ---[ end trace 4d135f3def21b4bd ]---
The code translates to the following in fs/pipe.c:alloc_pipe_info :
pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL);
if (pipe) {
pipe->bufs = kzalloc(sizeof(struct pipe_buffer) *
PIPE_DEF_BUFFERS, GFP_KERNEL); <=== this
if (pipe->bufs) {
init_waitqueue_head(>wait);
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
slab: odd BUG on kzalloc
Hi all,
I was fuzzing with trinity inside a KVM tools guest, running latest -next
kernel,
and hit the following bug:
[ 169.773688] BUG: unable to handle kernel NULL pointer dereference at
0001
[ 169.774976] IP: [81a15c2f] memset+0x1f/0xb0
[ 169.775989] PGD 93e02067 PUD ac1a2067 PMD 0
[ 169.776898] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 169.777923] Dumping ftrace buffer:
[ 169.778595](ftrace buffer empty)
[ 169.779352] Modules linked in:
[ 169.779996] CPU 0
[ 169.780031] Pid: 13438, comm: trinity Tainted: GW
3.8.0-rc7-next-20130215-sasha-3-gea816fa #286
[ 169.780031] RIP: 0010:[81a15c2f] [81a15c2f]
memset+0x1f/0xb0
[ 169.780031] RSP: 0018:8800aef19e00 EFLAGS: 00010206
[ 169.780031] RAX: RBX: RCX: 0080
[ 169.780031] RDX: RSI: RDI: 0001
[ 169.780031] RBP: 8800aef19e68 R08: R09: 0001
[ 169.780031] R10: 0001 R11: R12: 8800bb001b00
[ 169.780031] R13: 8800bb001b00 R14: 0001 R15: 00537000
[ 169.780031] FS: 7fb73581b700() GS:8800bb60()
knlGS:
[ 169.780031] CS: 0010 DS: ES: CR0: 80050033
[ 169.780031] CR2: 0001 CR3: aed31000 CR4: 000406f0
[ 169.780031] DR0: DR1: DR2:
[ 169.780031] DR3: DR6: 0ff0 DR7: 0400
[ 169.780031] Process trinity (pid: 13438, threadinfo 8800aef18000, task
8800aed7b000)
[ 169.780031] Stack:
[ 169.780031] 81269586 8800aef19e38 0280
81291a2e
[ 169.780031] 80d0aa39d9e8 8800aef19e48
8800aa39d9e8
[ 169.780031] 8800a65cc780 8800aa39d960 ffea
[ 169.780031] Call Trace:
[ 169.780031] [81269586] ? kmem_cache_alloc_trace+0x176/0x330
[ 169.780031] [81291a2e] ? alloc_pipe_info+0x3e/0xa0
[ 169.780031] [81291a2e] alloc_pipe_info+0x3e/0xa0
[ 169.780031] [81291ac6] get_pipe_inode+0x36/0xe0
[ 169.780031] [81291d63] create_pipe_files+0x23/0x140
[ 169.780031] [81291ebd] __do_pipe_flags+0x3d/0xe0
[ 169.780031] [81291fbb] sys_pipe2+0x1b/0xa0
[ 169.780031] [83d96135] ? tracesys+0x7e/0xe6
[ 169.780031] [8129204b] sys_pipe+0xb/0x10
[ 169.780031] [83d96198] tracesys+0xe1/0xe6
[ 169.780031] Code: 1e 44 88 1f c3 90 90 90 90 90 90 90 49 89 f9 48 89 d1 83
e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01
01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 66 66 66 90 66 66 66 90
66 66
[ 169.780031] RIP [81a15c2f] memset+0x1f/0xb0
[ 169.780031] RSP 8800aef19e00
[ 169.780031] CR2: 0001
[ 169.930103] ---[ end trace 4d135f3def21b4bd ]---
The code translates to the following in fs/pipe.c:alloc_pipe_info :
pipe = kzalloc(sizeof(struct pipe_inode_info), GFP_KERNEL);
if (pipe) {
pipe-bufs = kzalloc(sizeof(struct pipe_buffer) *
PIPE_DEF_BUFFERS, GFP_KERNEL); === this
if (pipe-bufs) {
init_waitqueue_head(pipe-wait);
Thanks,
Sasha
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
