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

[Ian Campbell <Ian.Campbell@citrix.com>]

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.