Signal from kernel space to user space

Signal from kernel space to user space

[Mai Daftedar]

Hi everyone
   Im still new to the kernel development world :)and  I was wondering
what functions I can use in the kernel space for a signal to be sent
to the userspace
I tryed a number of examples I found after I did some googling that
used the API "send_sig_info" however nothing worked :(


Any help would be appreciated
Can you please CC me in the reply to this mail
Thanks
Mai

Re: Signal from kernel space to user space

[Clemens Ladisch]

Mai Daftedar wrote:
>    Im still new to the kernel development world :)and  I was wondering
> what functions I can use in the kernel space for a signal to be sent
> to the userspace

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).

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?

> I tryed a number of examples I found after I did some googling that
> used the API "send_sig_info" however nothing worked :(

Because something in that code is wrong.  I can't tell you more about
the details because my crystal ball is in repair.


Best regards,
Clemens

Re: Signal from kernel space to user space

[Mark Hounschell]

Clemens Ladisch wrote:
> Mai Daftedar wrote:
>>    Im still new to the kernel development world :)and  I was wondering
>> what functions I can use in the kernel space for a signal to be sent
>> to the userspace
> 

I have some interest in this. Might I inject a couple of probably stupid related questions?

> 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?

> 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?
I have a PCI card that handles external interrupts from the outside world and does nothing but
report those external interrupts to userland. We use send_sig or wake_up_process depending
on whether userland is going to wait for it or not. If there is a better/faster way I would be
very interested.


Thanks and sorry for butting in
Mark

Re: Signal from kernel space to user space

[Davide Libenzi]

On Tue, 1 Dec 2009, Mark Hounschell wrote:

> If no "information" is required, which of these are the fastest, say from an interrupt handler?
> I have a PCI card that handles external interrupts from the outside world and does nothing but
> report those external interrupts to userland. We use send_sig or wake_up_process depending
> on whether userland is going to wait for it or not. If there is a better/faster way I would be
> very interested.

eventfd is. eventfd_signal() is also callable from non-sleeping contexts.


- Davide

Re: Signal from kernel space to user space

[Mai Daftedar]

Thanks all for the help,
 I needed to use signals just as interrupt signal from the kernel
space so that when a certain change occurs I'd be notified in the
userspace
 I used send_sig _info and it worked :)..The problem was with the
signal number I using a wong one..

 Thanks


> On Tue, Dec 1, 2009 at 8:05 PM, Davide Libenzi <davidel@xmailserver.org> wrote:
>>
>> On Tue, 1 Dec 2009, Mark Hounschell wrote:
>>
>> > If no "information" is required, which of these are the fastest, say from an interrupt handler?
>> > I have a PCI card that handles external interrupts from the outside world and does nothing but
>> > report those external interrupts to userland. We use send_sig or wake_up_process depending
>> > on whether userland is going to wait for it or not. If there is a better/faster way I would be
>> > very interested.
>>
>> eventfd is. eventfd_signal() is also callable from non-sleeping contexts.
>>
>>
>> - Davide
>>
>>
>

Re: Signal from kernel space to user space

[Clemens Ladisch]

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

Re: Signal from kernel space to user space

[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