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@xxxxxxxxxx Phone: (650) 506-8127 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
