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