Milosz Tanski <[email protected]> wrote:
> The honest answer is I don't know if it know if needs to be unlocked
> before or after. I saw a same pattern with unlocking order inside of
> __fscache_attr_changed in the failure case.
Following the enomem label, I'm calling fscache_unuse_cookie() which does this
without holding the lock in the same function.
I don't think the lock is required because:
(1) We hold a ref on cookie->n_active so the cookie cannot go away until we
release it, so calling __fscache_unuse_cookie() without the lock held
should be fine.
(2) wake_up_atomic_t() does not access cookie->n_active. The address is
merely needed as a key for the waiters to match on.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
