On Tue, 31 Jan 2012 16:54:44 +0200 Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > On 01/31/2012 01:57 AM, Jeff Layton wrote: > > WARNING: at lib/debugobjects.c:262 debug_print_object+0x8c/0xb0() > > > > For now, this patch is really just papering over that problem, but it > > should be "mostly harmless". That said, I'm ok with dropping it if > > Thomas is planning to fix this in the debugobjects code however. > > > > I disagree it's harmless. What if kmem_cache_free/kmem_cache_alloc deploys > a poisoning schema, in debug mode. Which stumps over memory. Is it > initialized then? > Different slab allocators handle that differently. As best I can tell: SLAB: calls ctor on the poisoned object before handing it back out SLUB: avoids poisoning the object if there's a ->ctor defined SLOB: I'm not sure -- haven't looked at it > What was the last state of the timer, is it safe for resume? > Yes, either way it's safe to reuse the recycled object, aside from the problem with debugobjects. If it's not then that's clearly a bug in the slab allocator. > For us this is a new object we should initialize it. > I tend to agree that not relying on slab ctor functions is preferable. They are widely used though so this problem almost assuredly exists in other places besides just rpc_pipefs. If it's not fixed in the debugobjects code (or the slab allocators) then I wouldn't be surprised if this popped up again in another area. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
