On Wed, Feb 03, 2016 at 11:24:33PM +0000, Filipe Manana wrote: > On Wed, Feb 3, 2016 at 11:19 PM, Liu Bo <bo.li.liu@xxxxxxxxxx> wrote: > > On Wed, Feb 03, 2016 at 08:26:50PM +0000, fdmanana@xxxxxxxxxx wrote: > >> So fix this by avoiding doing the nested read lock, which is easily > >> avoidable. This issue does not happen if task B calls write_lock() after > >> task A does the second call to read_lock(), however there does not seem > >> to exist anything in the documentation that mentions what is the expected > >> behaviour for recursive locking of rwlocks (leaving the idea that doing > >> so is not a good usage of rwlocks). > > > > iterate_inode_refs() does it in anothe way, it's using > > btrfs_clone_extent_buffer() to keep btrfs from similar deadlock, > > Yeah, I know, I made that fix long time ago. > > > it creates a clone so we don't have trouble on the original eb's read > > lock, it's more reasonable to me. > > Here it would be overkill to do similar approach, and it's a different > problem, we're not attempting to lock one leaf while having some other > leaf locked. We just want to transition a lock from spinning to > blocking mode - so it was silly to double read lock, we can do > directly the transition and make sure the release path call below > doesn't release the leaf. No need to waste memory and time cloning a > leaf. Yeah, this is just like unlock_up(), we just want to keep this one extent buffer locked. Filipe's patch should be fine. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
