On Tue, Sep 19, 2017 at 08:49:12AM -0400, Waiman Long wrote: > On 09/18/2017 08:01 PM, Christoph Hellwig wrote: > > Taking a look at this it seems like using a lock in struct block_device > > isn't the right thing to do anyway - all the action is on fields in > > struct blk_trace, so having a lock inside that would make a lot more > > sense. > > > > It would also help to document what exactly we're actually protecting. > > I think I documented in the patch that the lock has to protect changes > in the blktrace structure as well as the allocation and destruction of > it. Because of that, it can't be put inside the blktrace structure. The > original code use the bd_mutex of the block_device structure. I just > change the code to use another bd_fsfreeze_mutex in the same structure. Either way it has absolutely nothing to do with struct block_device, given that struct blk_trace hangs off the request_queue. Reusing a mutex just because it happens to live in a structure also generally is a bad idea if the protected data is in no way related. -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
