On Sat, 5 Apr 2014, Sasha Levin wrote:
> [ 1035.193166] Call Trace:
> [ 1035.193166] ? init_object (mm/slub.c:679)
> [ 1035.193166] setup_object.isra.34 (mm/slub.c:1071 mm/slub.c:1399)
> [ 1035.193166] new_slab (mm/slub.c:286 mm/slub.c:1439)
> [ 1035.193166] __slab_alloc (mm/slub.c:2203
On 04/07/2014 01:13 PM, Christoph Lameter wrote:
> On Sat, 5 Apr 2014, Sasha Levin wrote:
>
>> Unfortunately I've been unable to reproduce the issue to get more debug info
>> out of it. However, I've hit something that seems to be somewhat similar
>> to that:
>
> Could you jsut run with
On Sat, 5 Apr 2014, Sasha Levin wrote:
> Unfortunately I've been unable to reproduce the issue to get more debug info
> out of it. However, I've hit something that seems to be somewhat similar
> to that:
Could you jsut run with "slub_debug" on the kernel command line to get us
more diagnostics?
On Sat, 5 Apr 2014, Sasha Levin wrote:
Unfortunately I've been unable to reproduce the issue to get more debug info
out of it. However, I've hit something that seems to be somewhat similar
to that:
Could you jsut run with slub_debug on the kernel command line to get us
more diagnostics? Could
On 04/07/2014 01:13 PM, Christoph Lameter wrote:
On Sat, 5 Apr 2014, Sasha Levin wrote:
Unfortunately I've been unable to reproduce the issue to get more debug info
out of it. However, I've hit something that seems to be somewhat similar
to that:
Could you jsut run with slub_debug on the
On Sat, 5 Apr 2014, Sasha Levin wrote:
[ 1035.193166] Call Trace:
[ 1035.193166] ? init_object (mm/slub.c:679)
[ 1035.193166] setup_object.isra.34 (mm/slub.c:1071 mm/slub.c:1399)
[ 1035.193166] new_slab (mm/slub.c:286 mm/slub.c:1439)
[ 1035.193166] __slab_alloc (mm/slub.c:2203
On 03/26/2014 11:43 AM, Christoph Lameter wrote:
> On Tue, 25 Mar 2014, Sasha Levin wrote:
>
>> I'm not sure if there's anything special about this cache, codewise it's
>> created as follows:
>>
>>
>> inode_cachep = kmem_cache_create("inode_cache",
>>
On 03/26/2014 11:43 AM, Christoph Lameter wrote:
On Tue, 25 Mar 2014, Sasha Levin wrote:
I'm not sure if there's anything special about this cache, codewise it's
created as follows:
inode_cachep = kmem_cache_create(inode_cache,
On Tue, 25 Mar 2014, Sasha Levin wrote:
> I'm not sure if there's anything special about this cache, codewise it's
> created as follows:
>
>
> inode_cachep = kmem_cache_create("inode_cache",
> sizeof(struct inode),
>
On Tue, 25 Mar 2014, Sasha Levin wrote:
I'm not sure if there's anything special about this cache, codewise it's
created as follows:
inode_cachep = kmem_cache_create(inode_cache,
sizeof(struct inode),
On 03/25/2014 02:10 PM, Christoph Lameter wrote:
On Tue, 25 Mar 2014, Sasha Levin wrote:
So here's the full trace. There's obviously something wrong here since we
pagefault inside the section that was supposed to be running with irqs
disabled
and I don't see another cause besides this.
The
On Tue, 25 Mar 2014, Sasha Levin wrote:
> So here's the full trace. There's obviously something wrong here since we
> pagefault inside the section that was supposed to be running with irqs
> disabled
> and I don't see another cause besides this.
>
> The unreliable entries in the stack trace also
On Tue 25-03-14 12:06:36, Christoph Lameter wrote:
> On Tue, 25 Mar 2014, Michal Hocko wrote:
>
> > You are right. The function even does VM_BUG_ON(!irqs_disabled())...
> > Unfortunatelly we do not seem to have an _irq alternative of the bit
> > spinlock.
> > Not sure what to do about it.
On Tue 25-03-14 10:56:34, Michal Hocko wrote:
> On Tue 25-03-14 12:06:36, Christoph Lameter wrote:
> > On Tue, 25 Mar 2014, Michal Hocko wrote:
> >
> > > You are right. The function even does VM_BUG_ON(!irqs_disabled())...
> > > Unfortunatelly we do not seem to have an _irq alternative of the bit
On 03/25/2014 01:06 PM, Christoph Lameter wrote:
On Tue, 25 Mar 2014, Michal Hocko wrote:
You are right. The function even does VM_BUG_ON(!irqs_disabled())...
Unfortunatelly we do not seem to have an _irq alternative of the bit
spinlock.
Not sure what to do about it. Christoph?
Btw. it seems
On Tue, 25 Mar 2014, Michal Hocko wrote:
> You are right. The function even does VM_BUG_ON(!irqs_disabled())...
> Unfortunatelly we do not seem to have an _irq alternative of the bit
> spinlock.
> Not sure what to do about it. Christoph?
>
> Btw. it seems to go way back to 3.1 (1d07171c5e58e).
On Tue 25-03-14 11:54:43, Sasha Levin wrote:
> On 03/12/2014 12:25 PM, Sasha Levin wrote:
> >Hi all,
> >
> >While fuzzing with trinity inside a KVM tools guest running latest -next
> >kernel I've stumbled
> >on the following spew:
> >
> >[ 241.916559] BUG: unable to handle kernel paging request
On Tue, 25 Mar 2014, Sasha Levin wrote:
> I have a lead on this. Consider the following:
>
> kmem_cache_alloc
> __slab_alloc
> local_irq_save()
> deactivate_slab
> __cmpxchg_double_slab
> slab_unlock
>
On 03/12/2014 12:25 PM, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next kernel
I've stumbled
on the following spew:
[ 241.916559] BUG: unable to handle kernel paging request at 880029aa5e58
[ 241.917961] IP: []
On 03/12/2014 12:25 PM, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next kernel
I've stumbled
on the following spew:
[ 241.916559] BUG: unable to handle kernel paging request at 880029aa5e58
[ 241.917961] IP: [812c5fa3]
On Tue, 25 Mar 2014, Sasha Levin wrote:
I have a lead on this. Consider the following:
kmem_cache_alloc
__slab_alloc
local_irq_save()
deactivate_slab
__cmpxchg_double_slab
slab_unlock
On Tue 25-03-14 11:54:43, Sasha Levin wrote:
On 03/12/2014 12:25 PM, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next
kernel I've stumbled
on the following spew:
[ 241.916559] BUG: unable to handle kernel paging request at
On Tue, 25 Mar 2014, Michal Hocko wrote:
You are right. The function even does VM_BUG_ON(!irqs_disabled())...
Unfortunatelly we do not seem to have an _irq alternative of the bit
spinlock.
Not sure what to do about it. Christoph?
Btw. it seems to go way back to 3.1 (1d07171c5e58e).
Well
On 03/25/2014 01:06 PM, Christoph Lameter wrote:
On Tue, 25 Mar 2014, Michal Hocko wrote:
You are right. The function even does VM_BUG_ON(!irqs_disabled())...
Unfortunatelly we do not seem to have an _irq alternative of the bit
spinlock.
Not sure what to do about it. Christoph?
Btw. it seems
On Tue 25-03-14 10:56:34, Michal Hocko wrote:
On Tue 25-03-14 12:06:36, Christoph Lameter wrote:
On Tue, 25 Mar 2014, Michal Hocko wrote:
You are right. The function even does VM_BUG_ON(!irqs_disabled())...
Unfortunatelly we do not seem to have an _irq alternative of the bit
On Tue 25-03-14 12:06:36, Christoph Lameter wrote:
On Tue, 25 Mar 2014, Michal Hocko wrote:
You are right. The function even does VM_BUG_ON(!irqs_disabled())...
Unfortunatelly we do not seem to have an _irq alternative of the bit
spinlock.
Not sure what to do about it. Christoph?
On Tue, 25 Mar 2014, Sasha Levin wrote:
So here's the full trace. There's obviously something wrong here since we
pagefault inside the section that was supposed to be running with irqs
disabled
and I don't see another cause besides this.
The unreliable entries in the stack trace also
On 03/25/2014 02:10 PM, Christoph Lameter wrote:
On Tue, 25 Mar 2014, Sasha Levin wrote:
So here's the full trace. There's obviously something wrong here since we
pagefault inside the section that was supposed to be running with irqs
disabled
and I don't see another cause besides this.
The
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next kernel
I've stumbled
on the following spew:
[ 241.916559] BUG: unable to handle kernel paging request at 880029aa5e58
[ 241.917961] IP: [] deactivate_slab+0x103/0x560
[ 241.919439] PGD 88f9067 PUD 88fa067
Hi all,
While fuzzing with trinity inside a KVM tools guest running latest -next kernel
I've stumbled
on the following spew:
[ 241.916559] BUG: unable to handle kernel paging request at 880029aa5e58
[ 241.917961] IP: [812c5fa3] deactivate_slab+0x103/0x560
[ 241.919439] PGD
30 matches
Mail list logo
