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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-07-05 at 10:28 +0100, Daniel P. Berrange wrote:
> 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.

Thanks. I'm inclined towards not deleting the lock file.

Ian.



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