On 8/31/09, Florian Zumbiehl <florz@xxxxxxxx> wrote: > Hi, > >> > 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 guess so :-) > >> 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. > > Seems like a rather dirty solution to me - what about serializing any > directory creation/removal plus subsequent object creation using flock() > on a lock file? Would still need changes at every call site, of course ... That would limit paralellism to some degree. Retrys won't be needed very often; they would surely have a lower overhead. Less code too :-). It's not completely out of left field; both seqlocks and transactional memory use retries. There's no risk of livelock (i.e. infinite retries)... I'm lazy and don't want udev to run measurably slower. The only advantage I see of flock() is that it tells the reader "I'm a synchronization primitive, solving a concurrency problem here". I think we can get close enough by explaining the race in a comment next to the definition of create_path(). 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
