On Fri, Jul 18, 2003 at 09:52:33AM +0200, Oliver Neukum wrote:
> > > Any way, if you are serious, what make you consider it broken (no,
> > > not talking about personal preferences/phobias 8)
> >
> > There's unsolvable design issues in the way devfsd communication works
> > (with the last two patches the holes are closed as much as possible)
>
> Could you elaborate?
lookup is called with i_sem on parent, devfs calls up to devfsd in
lookup which might again do operation that would block on the same
i_sem. To avoid the deadlock we have to drop i_sem somewhere which
always introduces races. In 2.4 and earlier 2.5 theses races where
huge and easily exploitable at least with the O(1) scheduler. In
current 2.5 they're much smaller so you usually don't trip them but
they;re not going away as long as we keep the stateful devfsd design.
> > issues so people should switch to that ASAP. That doesn't mean we
> > can simply rip it out because people started to rely on the non-standard
> > device names, but it's use is pretty much discouraged in 2.6.
>
> How does udev avoid these complications?
udev is a hotplug upcall, not a stateful deamon.
> If udev doesn't have those issues, why can't they be fixed for devfsd?
Not without changing it to a stateless design, i.e. recreating something
resembling udev..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:32 EST