From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: [xen-unstable test] 13461: regressions - FAIL Date: Thu, 5 Jul 2012 10:28:35 +0100 Message-ID: <20120705092834.GE13884@redhat.com> References: <1341467373.14447.9.camel@dagon.hellion.org.uk> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1341467373.14447.9.camel@dagon.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Zhigang Wang , "xen-devel@lists.xensource.com" , "xen.org" List-Id: xen-devel@lists.xenproject.org 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 :|