Parallel hotplugging event issues

Rob Taylor rob.taylor at codethink.co.uk
Mon Mar 17 03:47:19 PDT 2008


Sjoerd Simons wrote:
> Hi,
> 
>   Attached is a patch to fix some basic issues with the parallel event
>   processing. The patch description has some more detailed information.

Patch looks good to me, please commit!

>   Unfortunately after this fix more issues show up. One specific issue i'm
>   seeing is that when pulling out my usb stick, the force unmounting fails to
>   work. Some analysis shows the issue is the following.
> 
>   The device tree looks something like this
>     *- A: scsi host device
>      *- B: block device (full device)
>       *- C: block device (one partition on the device
> 
>   When the usb device is pulled out removal events are received for all these
>   devices. The event dependency code properly detects that the full device
>   block device depends on the leaf block device. But not the relation between
>   the scsi_host and the block devices. So the event for A and C is handled in
>   parallel.
> 
>   Now when a device is removed, all it's child devices get removed too.. So the
>   event for A removes device C, causing the handlers of C to get confused (as C
>   is gone).. What this shows is that purely using the sysfs path prefixes for
>   dependency information isn't enough, the relationship of devices as hal has
>   detected them needs to be taken into account too.

That sounds like a good analysis of the problem to me. One choice is to 
force remove events to be fully serialised, as processing these in 
parallel has probably very little benefit.

>   Personally i'm not sure if it would be good to have the parallel event
>   processing in the next release. It might be better to back it out for now,
>   get the release out. And merge it afterwards, so that there is some more time
>   to work out all the issues with parallelizing these things. I'm afraid it
>   will keep triggering a lot of little issues for a while.

You could be right. The parallel event patch is a pretty large change, 
putting it in so close to release makes me a little nervous, and I wrote 
it! ;)

I'd certainly support reverting it before release then reinstating as 
first patch on the next development series to give us more time to eke 
out any problems (or make a branch for the release and revert there). We 
don't have to leave it as long to the next release as we did last... 
It's Danny's call though.

Thanks,
Rob


>   Sjoerd
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> hal mailing list
> hal at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/hal



More information about the hal mailing list