On 8/30/09, Florian Zumbiehl <florz@xxxxxxxx> wrote: > Hi, > >> On 8/29/09, Florian Zumbiehl <florz@xxxxxxxx> wrote: >> > as it's quite a bit of effort to actually verify this without much >> > knowlegde about the structure of udev: Could it happen that >> > util_create_path() and util_delete_path() do run in parallel for >> > the same directory? After all, util_create_path() does handle >> > the case where creation of the directory happens in parallel >> > to it running, so it doesn't seem all that unlikely to me ... >> >> Events on the same device are serialized. So you never have an "add" > > what is the "same device" identified by? I was thinking of the sysfs path. See event_queue_manager() and devpath_busy() in udevd.c. It looks like (minor:major, subsystem) is also checked; I don't know why. >> event running in parallel with a "remove" event for the same device. >> That covers most cases, but there might be an exception. >> >> Consider two CHANGE events running in parallel. Changes to symlinks >> are recorded under /dev/.udev/names. If the CHANGE events cause one >> symlink to be removed, and a new symlink to be created with the same >> name, I think you would get simultaneous calls to delete_path() and >> create_path(). > > I was actually thinking about the much simpler case where there could be > two completely independent objects that happen to reside in the same > directory, or at least below a common path prefix, and one of them is > being removed while the other one is being created. Wups. I thought that case couldn't happen for some reason, and then found the more complex case which is really just the same problem. So yes, I think this can happen. > Well, I guess that that's one of those bugs I don't have enough insight > into udev for fixing, as there probably is no local fix that just touches > a few lines within one function - so, any suggestions as to how to proceed? Hmm. This is the problem, right? 1 mkdir /dev/foo -> EEXIST 2 unlink /dev/foo/bar 2 rmdir /dev/foo -> success 1 mknod /dev/foo/qux -> ENOENT I think the solution is to audit the callers of create_path(), and fix them to retry indefinitely if the subsequent mknod / creat fails with ENOENT. 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
