Re: send_sig_info() in __switch_to() Ok or not?

Re: send_sig_info() in __switch_to() Ok or not?

[Andi Kleen]

Mikael Pettersson <mikpe@csd.uu.se> writes:

> I have a kernel extension (the x86 perfctr driver) that needs,
> in a specific but unlikely case(*), to send a SIGILL to current
> (next) in __switch_to(). Is this permitted or not?
>
> I suspect it might not be because send_sig_info() eventually does
> wake_up_process_kick(), and there's this warning in __switch_to()
> not to call printk() since it calls wake_up()...

> If I can't call send_sig_info() in __switch_to(), is there
> another way to post a SIGILL to current from __switch_to()?

You can just do it manually. Fill in the signal in the signal
mask of the process. The next time the process checks for signals it will 
kill itself. As it is already running or going to run it doesn't need
a wake up.

You could also forcibly call do_exit with the right signal, but
that cannot be blocked.

-Andi

Re: send_sig_info() in __switch_to() Ok or not?

[Mikael Pettersson]

Andi Kleen writes:
 > Mikael Pettersson <mikpe@csd.uu.se> writes:
 > 
 > > I have a kernel extension (the x86 perfctr driver) that needs,
 > > in a specific but unlikely case(*), to send a SIGILL to current
 > > (next) in __switch_to(). Is this permitted or not?
 > >
 > > I suspect it might not be because send_sig_info() eventually does
 > > wake_up_process_kick(), and there's this warning in __switch_to()
 > > not to call printk() since it calls wake_up()...
 > 
 > > If I can't call send_sig_info() in __switch_to(), is there
 > > another way to post a SIGILL to current from __switch_to()?
 > 
 > You can just do it manually. Fill in the signal in the signal
 > mask of the process. The next time the process checks for signals it will 
 > kill itself. As it is already running or going to run it doesn't need
 > a wake up.

Sorry about the delay in responding to this.
Anyway, I started doing it manually, but gave up since it would
mean copying/duplicating quite a bit of code from signal.c.
Instead I now do:

	BUG_ON(current->state != TASK_RUNNING);
	send_sig(SIG_ILL, current, 1);

I've checked sched.c and done runtime testing, and this does seem to
be true and work Ok. (Fingers crossed, knock on wood, etc.)

/Mikael

send_sig_info() in __switch_to() Ok or not?

[Mikael Pettersson]

I have a kernel extension (the x86 perfctr driver) that needs,
in a specific but unlikely case(*), to send a SIGILL to current
(next) in __switch_to(). Is this permitted or not?

I suspect it might not be because send_sig_info() eventually does
wake_up_process_kick(), and there's this warning in __switch_to()
not to call printk() since it calls wake_up()...

If I can't call send_sig_info() in __switch_to(), is there
another way to post a SIGILL to current from __switch_to()?

/Mikael

(*) A process on a HT P4 is using perfctrs and has an appropriate
cpus_allowed mask. Some other process changes our cpus_allowed,
and the scheduler migrates us to a non-0 thread. I detect this
in __switch_to()'s resume path and kill the counters, but I also
need to notify current somehow.