Signal from kernel space to user space
in [Kernel]
|
Prev: USB: Added USB_ETH_RNDIS to use instead of CONFIG_USB_ETH_RNDIS
Next: DFU Driver for Atheros bluetooth chipset AR3011
From: Clemens Ladisch on 2 Dec 2009 07:30 Mark Hounschell wrote: > Clemens Ladisch wrote: > > kill_pid_(info) is to be preferred over send_sig_info because it ensures > > that the destination process has the same identity (a plain pid number > > might have wrappend around and be in use by another process). > > Does that mean I can't assume my process pid will unique for the life of the process? The pid _does_ uniquely identify your process. However, after the process has died, it could be used for some new process, and send_sig_info would happily kill the new process. > > However, why are you using a signal? What information are you trying to > > send, and why wouldn't eventfd or a plain device thaz becomes readable > > be a better solution? > > If no "information" is required, which of these are the fastest, say > from an interrupt handler? If there really is no information, doing nothing would be fastest. ;-) If you want to tell userland that some event has happened, the various mechanisms are not much different as far as the kernel is concerned, as long as you don't have many thousands of events per seconds; the biggest problems for event delivery are scheduling the userland process for execution and handling of the event. Signals handlers interrupt any other userland code and therefore are not allowed to do much; therefore, I would strongly prefer to use some file handle that can be waited on with poll(). Furthermore, poll() allows to wait for multiple handles, and does not have the complexities of signal delivery and blocking. I would use signals only if the handler must interrupt any other running code, and if the signal can be handled completely without running into reentrancy problems. It is possible to handle signals with poll() by using signalfd, but when designing a new interface, one could just use eventfd instead. Best regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Eric W. Biederman on 3 Dec 2009 09:40
Clemens Ladisch <clemens(a)ladisch.de> writes: > Mark Hounschell wrote: >> Clemens Ladisch wrote: >> > kill_pid_(info) is to be preferred over send_sig_info because it ensures >> > that the destination process has the same identity (a plain pid number >> > might have wrappend around and be in use by another process). >> >> Does that mean I can't assume my process pid will unique for the life of the process? > > The pid _does_ uniquely identify your process. However, after the > process has died, it could be used for some new process, and > send_sig_info would happily kill the new process. send_sig_info isn't that bad as it takes a task struct. Plain pid_t's are just broken to use. A pid_t uniquely identifies a process within a pid namespace, not within all of the pid namespaces present on the kernel. >> > However, why are you using a signal? What information are you trying to >> > send, and why wouldn't eventfd or a plain device thaz becomes readable >> > be a better solution? >> >> If no "information" is required, which of these are the fastest, say >> from an interrupt handler? > > If there really is no information, doing nothing would be fastest. ;-) That or simply waking up the task. > If you want to tell userland that some event has happened, the various > mechanisms are not much different as far as the kernel is concerned, > as long as you don't have many thousands of events per seconds; the > biggest problems for event delivery are scheduling the userland process > for execution and handling of the event. > > Signals handlers interrupt any other userland code and therefore are > not allowed to do much; therefore, I would strongly prefer to use > some file handle that can be waited on with poll(). Furthermore, > poll() allows to wait for multiple handles, and does not have the > complexities of signal delivery and blocking. I would use signals only > if the handler must interrupt any other running code, and if the signal > can be handled completely without running into reentrancy problems. Plus signals have all kinds of weird latency and overhead. Outside of core kernel code, or subsystems where they are already used I would be surprised if signals could be done correctly and usefully. pid rollover isn't the only hidden gotcha. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |