On Tue, Jan 23, 2007 at 06:02:04PM +0100, Dieter Stüken wrote:
> The process of creating the mtab~ lock itself and
> placing the primary F_SETLK may be improved slightly.
>
> I'll try to implement this and send out a small patch, soon.
> Which version should I use to start, util-linux-2.13-pre7?
>
> Karel Zak wrote:
> > Step by step the locking:
> >
> > 1) mount creates unique file mtab~<pid>
>
> create the F_SETLK now! This ensures our lock is placed on this inode before
> any hard link is created. Keep this open lockfile_fd until we finally
> finished.
You don't understand. Sorry, but I don't want to do any change or
discuss about a "bug fix" if I don't see any problem with the current
code.
Please, show me a scenario when the current code doesn't work
correctly.
Karel
> >
> > 2) mount tries create hardlink from the unique file to generic mtab~
> >
> > -- this is important step. You cannot create the link if there is
> > already any other mtab~. The link() syscall is atomic operation.
> >
> > 3)
> > a) the mount can't create the hardlink
>
> open the already exiting mtab~ with a separate temporary fd.
>
> > -- well, let's use F_SETLKW as a conditional wait on foreign
> > mtab~ (= wait until there is not any other process with locked
> > mtab~))
> >
> > when the mtab~ is unlocked by a concurrent process the mount
> > tries everything __again__ from step 1)
>
> close temporary fd; return to step 2) instead.
> >
> > b) the mount is owner of the hardlink
> >
> > (it means -- we have created unique file and we have forced the file
> > as a generic mtab~ lock file. We win! We have the lock.)
>
> > Now the mount creates F_SETLK -- the reasons for this flock:
>
> already done, any exceptional condition avoided!
>
> > * the others concurrent processes will wait until we close
> > the mtab~ file.
> >
> > * stupid concurrent programs which don't use the trick with
> > link() and use only flock will wait on the lock too.
> >
> > 4) modify mtab
> >
> > 5) remove the mtab~ lock file
>
> 6) close saved lockfile_fd to wake up waiting processes.
>
> Even if we have two separate file descriptors involved now,
> it finally becomes much cleaner and less error prone.
>
> Dieter.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Karel Zak <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
