Re: [PATCH] sunrpc: initialize delayed work on each rpc_inode allocation

[Jeff Layton <jlayton@redhat.com>]

On Tue, 31 Jan 2012 16:54:44 +0200
Boaz Harrosh <bharrosh@panasas.com> 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@redhat.com>