From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [xen-unstable test] 13461: regressions - FAIL
Date: Thu, 5 Jul 2012 06:49:33 +0100
Message-ID: <1341467373.14447.9.camel@dagon.hellion.org.uk>
References: <osstest-13461-mainreport@xen.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <osstest-13461-mainreport@xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "xen.org" <ian.jackson@eu.citrix.com>
Cc: Zhigang Wang <zhigang.x.wang@oracle.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Daniel
	P. Berrange" <berrange@redhat.com>
List-Id: xen-devel@lists.xenproject.org

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.