[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xen 4.4.0 unnecessary dependency on Perl
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |