Re: [Xen-devel] [xen-unstable test] 13461: regressions - FAIL

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-07-05 at 12:53 +0100, Roger Pau Monne wrote:
> Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 13461: 
> > regressions - FAIL"):
> >>> +        flock -x $_lockfd
> >>> +        # We can't just stat /dev/stdin or /proc/self/fd/$_lockfd or
> >>> +        # use bash's test -ef because those all go through what is
> >>> +        # actually a synthetic symlink in /proc and we aren't
> >>> +        # guaranteed that our stat(2) won't lose the race with an
> >>> +        # rm(1) between reading the synthetic link and traversing the
> >>> +        # file system to find the inum.  Perl is very fast so use that.
> >>> +        rightfile=$( perl -e '
> >> Won't this need to become $(PERL) (or @PERL@ and some seddery at install
> >> time) for the benefit of BSD?
> >
> > This is in tools/hotplug/Linux.  AFAICT at least some of the BSDs have
> > an fstat(1).
> 
> BSD don't currently have any of this locking mechanism, which makes it 
> vulnerable to races regarding hotplug scripts launch. I think libxl 
> should be a better place to perform all this kind of locking, instead of 
> the hotplug scripts, which are already polluted enough, but as far as I 
> know we don't have any kind of inter-process locking mechanism right now?

The advantage of doing it this way (in the scripts) is that it is much
more fine grained. e.g. the script locks the iptables lock only for as
long as it is manipulating the firewall rules and so on. If libxl were
doing this it would have to lock for the entire duration of the script
which may end up needlessly serialising things.

Ian.


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