Messages in this thread | | | Date | Fri, 11 Apr 2003 11:52:45 -0700 | From | Greg KH <> | Subject | Re: [ANNOUNCE] udev 0.1 release |
| |
On Fri, Apr 11, 2003 at 08:12:05PM +0200, Oliver Neukum wrote: > > > > - There's a race with replugging, which you can do little about > > > > True, but this can get smaller. > > There isn't such a thing as a small race. Either there is a race or there > is no race. 'Should usually work' is not enough, especially when security > is concerned.
You are talking about the "issue" of /dev/foo going away because that device was removed, and then another device added which creates /dev/foo just as the user starts to open /dev/foo? Or something else?
> > > - Error handling. What do you do if the invocation ends in EIO ? > > > > Which invocation? From /sbin/hotplug? > > Yes. > This is a serious problem. Your scheme has very nasty failure modes. > By implementing this in user space you are introducing additional > failure modes. > - You need disk access -> EIO
If udev becomes a deamon, disk access isn't needed. Actually the current version of udev doesn't require any disk access, other than loading it into memory.
> - You have no control over memory allocation -> ENOMEM, EIO in swap space > Usually I'd not care about EIO, but here security is threatened. EIO crashing > the system under some circumstances is inevitable, EIO opening a security > hole is not acceptable however.
So yes, doing this in userspace causes a number of these kinds of "problems". The same kinds of "problems" that all other user programs have to deal with, right?
So, if udev can't be read from the disk, the machine isn't in a very workable state, creating that new device node is going to be the least of your worries.
If udev can't get access to memory (actually it does no malloc calls, so it would have to run out of stack space), or there is no memory to load udev into memory, then again, you have a unstable machine, and there's not much else we can do about it.
> 4000 spawnings is 32MB for kernel stacks alone. > You cannot assume that resources will be sufficient for that.
If you have 4000 disks, you have to have a _lot_ of memory just to deal with it. See the other 4000 disk threads for more discussions about this issue.
If we fix up the kernel to handle that many different disks, then userspace can surely handle 4000 tasks (it can handle that today, right?)
Anyway, it will be quite difficult to plug 4000 disks in "all at once". There is a time delay inbetween discovering each of those disks from within the kernel, not to mention the physical issues of spinning them all up.
> That again is a serious problem, because you cannot resync. > If you lose a 'remove' event you're screwed.
Yes, if you lose a remove, things can get out of whack. My goal is to not lose any.
> And of course, what do you do if the driver is not yet loaded?
Nothing. udev requires that the kernel assign a major/minor to a device, which means that a driver has to be bound to the device. Binding drivers to devices is the current hotplug task, and has nothing to do with udev (with the exception that we have to be able to call both programs for each hotplug event, but I'm working on that.)
thanks,
greg k-h - 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/
| |