On 9/7/09, Florian Zumbiehl <florz@xxxxxxxx> wrote: > Hi, > >> On Mon, Sep 7, 2009 at 22:23, Florian Zumbiehl <florz@xxxxxxxx> wrote: >> >> until we successfully create the dir and the node or link, but in real >> >> world setups it seems it just does not happen. That way we don't put >> > >> > How do you know that? >> >> Competing events for the same subdir but different devices are pretty >> rare. And it's very unlikely that shared directories ever get empty, >> most of them have always some device which stays around and pins the > > It seems unlikely per call to those functions, sure. But given the > number of installations, and the number of calls per installation ... > >> subdir. And there is no such known problem ever reported. > > Now, how likely is it that when this happens once in a setup and it's > not reproducible, it would get reported? > > As an argument for a retry loop instead of locking, that seems fine - > but to conclude from that that it seems not to happen in real world > setups, I think, is not appropriate. > > Florian > One scenario which came to mind was quickly moving an SD card between card readers, where (for some hardware) we rely on HAL polling to detect media changes. The by-disk/label links could then be subject to this race, assuming thereare no other labelled filesystems. And I believe linux systems are often installed without labelling the filesystems. So IMO this will occasionally happen on real-world systems. Even though it's a contrived sequence of events, and it's unlikely to matter because no-one relies on disk/by-label links on removable media. There could be scenarios I've missed. And they do seem even less likely to be reported than they are to happen :-). If this can be fixed as simply as adding a loop around create_path() and mknod(), I think we should. (Plus some re-arranging to avoid nesting the loops in udev-node.c). Regards Alan -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
