Even if it were only a situation of allocating, I don't like the loop,
because it means you can end up allocating twice for no reason.
More importantly, the loop you used doesn't protect insertions into
the table. So it's not safe on SMP.
Anyway, I've already fixed the allocation race you're concerned about,
plus the insertion race, in my tree (using a semaphore).
> > perfect solution anyway. I'm fixing this (and other races) with proper
> > locking. If you went to the trouble to start patching, why at least
> > didn't you do it cleanly with a lock?
> Because it means adding a per-superblock lock for no good reason.
Well, it's just a single lock (only one devfs superblock possible).
And this is generally a low-contention case (new devfs entries are not
created that often). Using the lock also keeps the code simpler.
> PS: ObYourPropertyManager: karmic retribution?
Um, retribution for putting in an awful lot of time developing devfs
(despite extreme hostility), at considerable personal sacrifice, and
being patient and civilised to those who flamed against it? My, how
I've been such a horrible person.
I find your comment on karmic retribution repugnant.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/