Milosz Tanski <milosz@xxxxxxxxx> 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
--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cachefs
