On Wed, Nov 30, 2016 at 5:09 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Wed, Nov 30, 2016 at 3:49 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: ... >> >> So why invent a new private lock when the overlay inode lock is perfectly >> valid for the job? >> >> After we have the inode lock in place, lock_rename() is taken when it is >> needed for a specific operation (when either upperdir or workdir need to >> be locked), so releasing it for data copy up is just a free gift. >> >> Hope that I managed to clarify rather then confuse more. > > It is documented and easy to verify that inode lock is held by the VFS > for all but one case of copy_up(). However that one exception is not > documented and pretty hard to verify. I.e. if there's a call path > that results in d_real() being called with inode lock, it's going to > deadlock. And if that call path is hard to trigger, then testing > won't reveal this and the bug can remain undetected for a long time. > I see. I stand corrected. So I'll let you find the right candidate for copy up lock. Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
