On Thu, Sep 22, 2016 at 12:24:07PM -0400, Jeff Mahoney wrote: > This isn't necessarily a comment on this code in particular, but what's > the reason for using call_rcu to defer the freeing instead of > synchronize_rcu and freeing the device directly via __free_device (if it > accepted a btrfs_device)? It's a pattern that's used throughout > volumes.c and it's old[1]. I'm not sure if it was intentional to defer > freeing since that was actually a functional change from the code it > replaced.
It could be unintentional, the patch was supposed to relax the read-only side, ie. use RCU instead of mutex. Deferred freeing does not seem to be necessary. The device locking code needs cleanup/refactoring. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
