Re: [RFC 02/22] configfs: Add struct configfs_item_operations->check_link() in configfs_unlink()

[Joel Becker <Joel.Becker@oracle.com>]

On Wed, Sep 08, 2010 at 01:53:27PM -0700, Nicholas A. Bellinger wrote:
> On Wed, 2010-09-08 at 12:26 -0700, Joel Becker wrote:
> So after re-running this again, I was a bit off about where the OOOPs is
> actually occuring.  So, the OOPs does not occur during in the simple
> example here with the first unlink(2):
> 
> 	unlink sub_child/group1/src_0/src_link
> 
> but rather after the second unlink(2) is called after the first for
> src_link occurs:
> 
> 	unlink sub_child/group2/dst_0/dst_link
> 
> So back to the OOPs with the current TCM code example, on v2.6.36-rc3
> this actually triggers a SLUB warning "Object already free" from inside
> of TCM code. This is attributed to the releasing a specific LUN ACLs
> from the second unlink(2)'s struct config_item_operations->drop_link(),
> that the first unlink had already released.  This is because the first
> unlink(2) will currently assume that the remaining LUN ACLs are safe to
> release because, it still assumes the disabled check_link call.

	The trivial solution is to refcount your ACLs.  You get both
allow_link() calls, so you should be able to increment a counter there,
and then drop them when the last drop_link() call is made.  That will
keep your consumer structures around until all links are exhausted.

Joel

-- 

"I'm so tired of being tired,
 Sure as night will follow day.
 Most things I worry about
 Never happen anyway."

Joel Becker
Consulting Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127