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

From: Joel Becker
Date: Fri Sep 10 2010 - 11:30:43 EST


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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/