Re: [Xen-devel] xen 4.4.0 unnecessary dependency on Perl

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Anthony Wright writes ("Re: [Xen-devel] xen 4.4.0 unnecessary dependency on 
Perl"):
> Below is a patch that converts the perl script into shell script. I'm new to 
> submitting patches, so I apologise if this is the wrong way to do it.

This patch is pretty good.  We also need you to sign it off, and it
would be good if you could provide a commit message.  See `Signing off
a patch' in
  http://wiki.xen.org/wiki/Submitting_Xen_Patches

> I believe the patch provides the same functionality as the perl, but it does 
> exactly what the comment says isn't good enough.

I agree with you that the comment is wrong.

It is wrong for two entirely separate reasons:


I.

No-one unlinks the lockfile unless they have it locked.  (This is an
essential part of this locking protocol.)  (And, no-one will re-link
into the filesystem an unlinked lockfile.)  That means that if we have
successfully locked a file then either:

 1. The lockfile name referred to the file we have flocked at the time
    we flocked it.  This means that at that time, we were the holder
    of the abstract lock.  We haven't released the abstract lock (by
    removing the flock or unlinking the file).  Therefore no-one else
    is allowed to have deleted the file after that time and no-one is
    racing with our stat to delete the file.

or:

 2. The lockfile name already referred to a different file, or no file
    at all, when we flocked the file we have open.  That means that at
    the time we got the flock, our file was already unlinked.  We have
    therefore definitely lost the race; again, our stat of our open
    file is not racing with the task which unlinked it - the unlink
    happened earlier.

II.

It is not the case that stat -L /proc/self/fd/N works by reading the
synthetic link target (with or as if by readlink(2)) and then doing a
filesystem path lookup on the reported link target path.  stat(1)
given -L calls stat(2) rather than lstat(2).  stat(2) on
/proc/self/fd/N accesses the actual open file object (found via the
process's file table) without regard to the name(s) it may or may not
now have:

$ exec 3<>t
$ stat -c %i t
813539
$ ls -i t
813539 t
$ stat -L -c %i /proc/self/fd/3
813539
$ rm t
$ stat -L -c %i /proc/self/fd/3
813539
$ stat -c %i t
stat: cannot stat `t': No such file or directory
$ stat -c %i "`readlink /proc/self/fd/3`"
stat: cannot stat `/u/iwj/t (deleted)': No such file or directory
$


So,

Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel