Michal Suchanek <hramrach@xxxxxxxxxx> writes: > On 12 July 2011 10:30, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> Michal Suchanek <hramrach@xxxxxxxxxx> writes: >> >>> The locking order is likely determined by the structure of the union >>> and not some system-wide order of filesystems so assuming the readonly >>> layers are locked as well you will probably get a deadlock with >>> technically correct mount: >>> >>> mount -t overlayfs overlayfs -olowerdir=/lower2,upperdir=/upper /tmpoverlay >>> mount -t overlayfs overlayfs -olowerdir=/lower1,upperdir=/tmpoverlay /overlay >>> >>> mount -t overlayfs overlayfs -olowerdir=/lower1,upperdir=/upper2 /tmpoverlay2 >>> mount -t overlayfs overlayfs -olowerdir=/lower2,upperdir=/tmpoverlay2 /overlay2 >>> >>> because now lower1 and lower2 are differently ordered in the two >>> overlays. >> >> Overlayfs never locks both upper and lower at the same time, which means >> there's no AB-BA locking dependency. The lock orderings are: >> >> -> /overlay >> -> /lower1 >> -> /tmpoverlay >> -> /lower2 >> -> /upper >> -> /overlay2 >> -> /lower2 >> -> /tmpoverlay2 >> -> /lower1 >> -> /upper2 >> >> As you can see there's no nesting of lower2 and lower1 into each other. >> >> When you combine two filesystems, a completely new ordering is created >> each time, there's no possibility to make an AB-BA nesting. At least I >> cannot see one. > > Except you can get in situation where overlay locks lower1 and > tmpoverlay waits for lower2 Note: tmpoverlay lock does *not* nest into lower1 lock, they are both on the same nesting level. There's no dependency between the two. > which is held by overlay2 waiting for > lower1 in tmpoverlay2. No deadlock there. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
