![]() | |||||||||||||
Messages in this thread |
Tim Hockin wrote: >On Tue, Jan 20, 2004 at 07:14:12PM +1100, Nick Piggin wrote: >>>>Under what conditions? Not arbitrary entropy, surely. If a hotplug script >>>is present and does not blow up, it should be safe to assume it will be run >>>upon an event being delivered. If not, we have a WAY bigger problem :) >>>>>>>>That assumption is not safe. The main problems are of course process limits >>and memory allocation failure.>>>>If root has a process limit that make hotplug scripts fail to run, then >we're hosed in a lot of ways. And if we fail to allocate memory, there >really ought to be some retry or something. It seems to me that a failure >to run a hotplug script is a BAD THING.> (or OOM killed being another that comes to mind) It is sometimes inevitable. With that knowledge we should be designing for graceful failure. >>>>Sending it a SIGPWR means you have to run it on a different CPU that it was >>>affined to, which is already a violation.>>>>>At least the task has the option to handle the problem. >>>>But it is a violation of the affinity. As the kernel we CAN NOT know what >the affinity really means.> Not if the application is designed to handle it. How would hotplug scripts make this any different, anyway? > Maybe there is some way for a task to indicate >it would like to receive SIGPWR in that case. Or some other signal. Can we >invent new signals? > >That way a task that KNOWS about the CPU disappearing underneath it can be >wise, while everything else will not just get killed. > Rusty thought you just wouldn't send it unless the process was handling it. - 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/ | ||||||||||||
| Last update: 2005-03-22 14:00 [from the cache] ©2003-2008 | |||||||||||||