Re: Signal from kernel space to user space

[ebiederm@xmission.com (Eric W. Biederman)]

Clemens Ladisch <clemens@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