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

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Thu, Jul 05, 2012 at 06:49:33AM +0100, Ian Campbell wrote:
> On Thu, 2012-07-05 at 05:23 +0100, xen.org wrote:
> > flight 13461 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/13461/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-pv           18 leak-check/check          fail REGR. vs. 
> > 13459
> >  test-amd64-amd64-pv          18 leak-check/check          fail REGR. vs. 
> > 13459
> 
> http://www.chiark.greenend.org.uk/~xensrcts/logs/13461/test-amd64-amd64-xl/18.ts-leak-check.log:
> 2012-07-05 01:45:13 Z LEAKED [file /var/run/xen-hotplug/iptables] file: 
> 465271    0 -rw-r--r--   1 root     root            0 Jul  5 02:37 
> /var/run/xen-hotplug/iptables
> 2012-07-05 01:45:13 Z LEAKED [file /var/run/xen-hotplug/block] file: 465252   
>  0 -rw-r--r--   1 root     root            0 Jul  5 02:38 
> /var/run/xen-hotplug/block
> 
> This is obviously as a result of the "hotplug/Linux: use flock based
> locking" changes.
> 
> However it isn't clear to me that this isn't a feature of the way flock
> based locking works, since it locks on (I guess) the underlying inode
> not the path, such that cleaning up these files in release_lock would be
> incorrect because two invocations would end up effectively taking
> different locks despite using the same path:
> 
>       Thread A        Thread B        Thread C
>       claim /foo
>                       claim /foo
>                       blocks
>       release /foo
>       rm /foo
>                       unblock
>                                       claim /foo
>                                       new /foo -- doesn't block!
> 
> Both B and C have "the" lock.
> 
> Is that correct?

Yes, as you say flock() operates on the inode, so if something deletes
and recreates the file, future flocks will operate differently. Ideally
you should just never rm the files at all.

If you need to 'rm' them, then to avoid this, you must do two things

 - Only 'rm /foo' while holding the lock on /foo
 - Record the inode before acquiring the lock. After acquiring the
   lock check whether the inode on disk is the same. If not,
   release the lock & repeat.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

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