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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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?

Ian.


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