On 12/19/13 13:12, Bart Van Assche wrote:
> On 12/17/13 20:53, Sasha Levin wrote:
>> I'm still seeing warnings with this patch applied:
>>
>> [ 24.900482] WARNING: CPU: 12 PID: 3654 at lib/debugobjects.c:260
>> debug_print_object+0x8d/0xb0()
>> [ 24.900482] ODEBUG: free active (active state 0)
On 12/17/13 20:53, Sasha Levin wrote:
> I'm still seeing warnings with this patch applied:
>
> [ 24.900482] WARNING: CPU: 12 PID: 3654 at lib/debugobjects.c:260
> debug_print_object+
> 0x8d/0xb0()
> [ 24.900482] ODEBUG: free active (active state 0) object type:
> timer_list hint: delay
> ed_wo
On 12/17/2013 03:37 PM, Christoph Lameter wrote:
On Tue, 17 Dec 2013, Sasha Levin wrote:
I'm still seeing warnings with this patch applied:
Looks like this is related to some device release mechanism that frees
twice?
I do not see any kmem_cache management functions in the backtrace and
ther
On Tue, 17 Dec 2013, Sasha Levin wrote:
Cc'ing RTC folks
> I'm still seeing warnings with this patch applied:
That's not a sl*b issue.
> [ 24.900482] WARNING: CPU: 12 PID: 3654 at lib/debugobjects.c:260
> debug_print_object+
> 0x8d/0xb0()
> [ 24.900482] ODEBUG: free active (active state 0)
On Tue, 17 Dec 2013, Sasha Levin wrote:
> I'm still seeing warnings with this patch applied:
Looks like this is related to some device release mechanism that frees
twice?
I do not see any kmem_cache management functions in the backtrace and
therefore would guess that this is not the same issue.
On 12/03/2013 10:22 AM, Christoph Lameter wrote:
On Mon, 2 Dec 2013, Greg KH wrote:
Your release function had 2 tabs for the lines, not one.
Ah ok. Fixed.
Index: linux/include/linux/slub_def.h
===
--- linux.orig/include/linux/s
On Mon, 2 Dec 2013, Greg KH wrote:
> Your release function had 2 tabs for the lines, not one.
Ah ok. Fixed.
> > > > Index: linux/include/linux/slub_def.h
> > > > ===
> > > > --- linux.orig/include/linux/slub_def.h 2013-12-02 13:31:0
On Mon, Dec 02, 2013 at 09:55:49PM +, Christoph Lameter wrote:
> On Mon, 2 Dec 2013, Greg KH wrote:
>
> > > Signed-off-by: Christoph Lameter
> >
> > That looks good, if you fix the indentation issue :)
>
> Huh?
Your release function had 2 tabs for the lines, not one.
> > > Index: linux/inc
On Mon, 2 Dec 2013, Greg KH wrote:
> > Signed-off-by: Christoph Lameter
>
> That looks good, if you fix the indentation issue :)
Huh?
> > Index: linux/include/linux/slub_def.h
> > ===
> > --- linux.orig/include/linux/slub_def.h
On Mon, Dec 02, 2013 at 07:41:15PM +, Christoph Lameter wrote:
> On Mon, 2 Dec 2013, Greg KH wrote:
>
> > No, the release callback is in the kobj_type, not the kobject itself.
>
> Ahh... Ok. Patch follows:
>
>
> Subject: slub: use sysfs'es release mechanism for kmem_cache
>
> Sysfs has a r
On Mon, 2 Dec 2013, Greg KH wrote:
> No, the release callback is in the kobj_type, not the kobject itself.
Ahh... Ok. Patch follows:
Subject: slub: use sysfs'es release mechanism for kmem_cache
Sysfs has a release mechanism. Use that to release the
kmem_cache structure if CONFIG_SYSFS is enabl
On Mon, 2 Dec 2013, Greg KH wrote:
> >
> > We need our own reference count. So we just have to defer the
> > release of the kmem_cache struct until the ->release callback is
> > triggered. The put of the embedded kobject must be the last action on the
> > kmem_cache structure which will then trig
On Mon, Dec 02, 2013 at 07:00:23PM +, Christoph Lameter wrote:
> On Mon, 2 Dec 2013, Greg KH wrote:
>
> > >
> > > We need our own reference count. So we just have to defer the
> > > release of the kmem_cache struct until the ->release callback is
> > > triggered. The put of the embedded kobjec
On Mon, 2 Dec 2013, Greg KH wrote:
> On Mon, Dec 02, 2013 at 04:33:20PM +, Christoph Lameter wrote:
> > On Wed, 27 Nov 2013, Greg KH wrote:
> >
> > > Just make the kobject "dynamic" instead of embedded in struct kmem_cache
> > > and all will be fine. I can't believe this code has been broken
On Mon, Dec 02, 2013 at 05:18:16PM +, Christoph Lameter wrote:
> On Mon, 2 Dec 2013, Greg KH wrote:
>
> > On Mon, Dec 02, 2013 at 04:33:20PM +, Christoph Lameter wrote:
> > > On Wed, 27 Nov 2013, Greg KH wrote:
> > >
> > > > Just make the kobject "dynamic" instead of embedded in struct kme
On Wed, 27 Nov 2013, Greg KH wrote:
> Just make the kobject "dynamic" instead of embedded in struct kmem_cache
> and all will be fine. I can't believe this code has been broken for
> this long.
The slub code is was designed to use an embedded structure since we
only get the kobj pointer passed
On Mon, Dec 02, 2013 at 04:33:20PM +, Christoph Lameter wrote:
> On Wed, 27 Nov 2013, Greg KH wrote:
>
> > Just make the kobject "dynamic" instead of embedded in struct kmem_cache
> > and all will be fine. I can't believe this code has been broken for
> > this long.
>
> The slub code is was
On Wed, Nov 27, 2013 at 02:44:58PM +0100, Thomas Gleixner wrote:
> On Wed, 27 Nov 2013, Russell King - ARM Linux wrote:
>
> > On Wed, Nov 27, 2013 at 01:32:31PM +, Russell King - ARM Linux wrote:
> > > On Wed, Nov 27, 2013 at 02:29:41PM +0100, Thomas Gleixner wrote:
> > > > Though the kobject
On Wed, 27 Nov 2013, Russell King - ARM Linux wrote:
> On Wed, Nov 27, 2013 at 01:32:31PM +, Russell King - ARM Linux wrote:
> > On Wed, Nov 27, 2013 at 02:29:41PM +0100, Thomas Gleixner wrote:
> > > Though the kobject is the only thing which has a delayed work embedded
> > > inside struct kme
On Wed, 27 Nov 2013, Russell King - ARM Linux wrote:
> On Wed, Nov 27, 2013 at 02:29:41PM +0100, Thomas Gleixner wrote:
> > Though the kobject is the only thing which has a delayed work embedded
> > inside struct kmem_cache. And the debug object splat points at the
> > kmem_cache_free() of the s
On Wed, Nov 27, 2013 at 01:32:31PM +, Russell King - ARM Linux wrote:
> On Wed, Nov 27, 2013 at 02:29:41PM +0100, Thomas Gleixner wrote:
> > Though the kobject is the only thing which has a delayed work embedded
> > inside struct kmem_cache. And the debug object splat points at the
> > kmem_cac
On Wed, Nov 27, 2013 at 02:29:41PM +0100, Thomas Gleixner wrote:
> Though the kobject is the only thing which has a delayed work embedded
> inside struct kmem_cache. And the debug object splat points at the
> kmem_cache_free() of the struct kmem_cache itself. That's why I
> assumed the wreckage aro
On Wed, 27 Nov 2013, Russell King - ARM Linux wrote:
> On Wed, Nov 27, 2013 at 11:45:17AM +0100, Thomas Gleixner wrote:
> > On Wed, 27 Nov 2013, Pablo Neira Ayuso wrote:
> >
> > > On Tue, Nov 26, 2013 at 02:11:57PM -0500, Sasha Levin wrote:
> > > > Ping? I still see this warning.
> > >
> > > Did
On Wed, Nov 27, 2013 at 11:45:17AM +0100, Thomas Gleixner wrote:
> On Wed, 27 Nov 2013, Pablo Neira Ayuso wrote:
>
> > On Tue, Nov 26, 2013 at 02:11:57PM -0500, Sasha Levin wrote:
> > > Ping? I still see this warning.
> >
> > Did your test include patch 0c3c6c00c6?
>
> And how is that patch supp
On Wed, 27 Nov 2013, Pablo Neira Ayuso wrote:
> On Tue, Nov 26, 2013 at 02:11:57PM -0500, Sasha Levin wrote:
> > Ping? I still see this warning.
>
> Did your test include patch 0c3c6c00c6?
And how is that patch supposed to help?
> > >[ 418.312449] WARNING: CPU: 6 PID: 4178 at lib/debugobjects
On 11/26/2013 06:07 PM, Pablo Neira Ayuso wrote:
On Tue, Nov 26, 2013 at 02:11:57PM -0500, Sasha Levin wrote:
>Ping? I still see this warning.
Did your test include patch 0c3c6c00c6?
Yeah, it reproduces with today's -next tree, which includes that commit.
Thanks,
Sasha
--
To unsubscribe fr
On Tue, Nov 26, 2013 at 02:11:57PM -0500, Sasha Levin wrote:
> Ping? I still see this warning.
Did your test include patch 0c3c6c00c6?
> On 09/07/2013 09:10 AM, Sasha Levin wrote:
> >Hi all,
> >
> >While fuzzing with trinity inside a KVM tools guest, running latest -next
> >kernel, I've
> >stumb
Ping? I still see this warning.
On 09/07/2013 09:10 AM, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest, running latest -next
kernel, I've
stumbled on the following:
[ 418.311956] [ cut here ]
[ 418.312449] WARNING: CPU: 6 PID: 4178 at
Hi all,
While fuzzing with trinity inside a KVM tools guest, running latest -next
kernel, I've
stumbled on the following:
[ 418.311956] [ cut here ]
[ 418.312449] WARNING: CPU: 6 PID: 4178 at lib/debugobjects.c:260
debug_print_object+0x8d/0xb0()
[ 418.313243] ODEBUG:
29 matches
Mail list logo
