[parted-devel] Possible Race Condition using test code, libparted, and Fedora 12

Karel Zak kzak at redhat.com
Thu Jan 7 21:54:56 UTC 2010


On Thu, Jan 07, 2010 at 02:57:19PM +0100, Petr Uzel wrote:
> On Mon, Jan 04, 2010 at 12:58:25PM -0700, Curtis Gedak wrote:
> > Curtis Gedak wrote:
> > >I will try out the two patches plus the one you emailed on a
> > >pristine copy of parted-1.9.0.  After running my tests I will
> > >report back here.
> > 
> > Unfortunately, my testing of the above quoted situation on Fedora 12
> > shows that the test fails on the first iteration.  This failure
> > occurred each and every time I ran the test.  Hence this problem is
> > still unresolved.
> 
> Hm, that doesn't look much better :)
> 
> I'm experiencing similar (or maybe the same ?) problem on SUSE with
> parted-1.8.8. Sometimes, if I create a partition and immediately
> afterwards I try to remove the partition, the kernel doesn't get
> informed. The pseudoscript(tm) I'm using:
> 
> ---
> #!/bin/bash
> parted -s /dev/sdX mkpart primary 0 10M
> parted -s /dev/sdX rm 1
> grep /dev/sdX1 /proc/partitions && report error
> ---
> 
> If I run this in a cycle, after several iterations it fails,
> because sdX1 is deleted from on-disk table, but it is still
> present in /proc/partitions.
> 
> It seems to be really sensitive to timing, because if I e.g.
> run the 'parted rm' via strace, the probability of failure
> decreases significantly.
> 
> Idea: something must be touching /dev/sdX1 while parted is
> deleting it. So I've put 'lsof /dev/sdX1' between those two
> parted calls -> some hal related crap is touching /dev/sdX1.

 I guess it's udevd (on new distros). It checks by inotify for
 filesystem changes to maintain /dev/disk/by-* symlinks.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



More information about the parted-devel mailing list