[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