8 Jan 2007 16:58
mtab locking
Hi, after I switched to an SMP system now, I sporadically got a broken /etc/mtab again. I unanalyzed the actual code and came down to lock_mtab() within mount/fstab.c. This function was patched/improved/repaired over and over again and still today each distribution supplies its own patches to get it fixed. After some days of analyzing it, I came to the conclusion, that there is a principal problem to get the locking work safely with the current concept (or I do not understand how it is supposed to work, and someone can explain it to me). The strategy seems to place an F_WRLCK on mtab~ to proceed modifying mtab itself. If no current ~mtab was found, a new one is created and finally removed again. Thus the creation/deletion are independent of the flock itself. I think this is the root of all problems: either the placement of the flock is the semaphore; in this case the lock file should never be deleted. Or the creation/existence of the lockfile is the semaphore. In this case the flock helps to notify waiting mount processes, but it is not the semaphore itself. There was a major patch around util-linux-2.9i to improve this, but besides a lot of very confusing if/else/while(ntry++<5) constructs, it does not solve the problem in principal. In addition there are a couple of patches around to handle additional races, but they are making things even more complicated. This broken concept also went into other packages i.e. mount.nfs. For all solutions currently around, the possibility remains, to place an flock on a foreign mtab~ file, which may get removed by someone else before the update if mtab itself was finished(Continue reading)
.
This issue is definitely somethig what should be fixed in a next
release. But don't forget that the mount command is not alone, there
is more utils that modify /etc/mtab.
There is also other issue -- some people look for way how support
read-only root fs and how move the /etc/mtab~ lock file to /var/lock.
> again. I unanalyzed the actual code and came down to lock_mtab() within
> mount/fstab.c. This function was patched/improved/repaired over and over again
> and still today each distribution supplies its own patches to get it fixed.
Red Hat patch:
There is one bug only.
> I do not understand how it is supposed to work, and someone can explain it to me).
>
> The strategy seems to place an F_WRLCK on mtab~ to proceed modifying mtab itself.
> If no current ~mtab was found, a new one is created and finally removed again.
> Thus the creation/deletion are independent of the flock itself.
No. The core of the strategy is not F_WRLCK , but the link().
Step by step the locking:
1) mount creates unique file mtab~<pid>
2) mount tries create hardlink from the unique file to generic mtab~
RSS Feed