[lkml]   [2010]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
SubjectRe: situation with signals
On 10/27/2010 5:37 PM, Al Viro wrote:
> On Wed, Oct 27, 2010 at 05:02:10PM -0400, Chris Metcalf wrote
>> I set aside this thread to look at when I had a minute, and I believe there
>> is just one of the signal issues present in the tile code. The fix is to
>> reset regs->fault to something other than the "syscall" fault type when
>> exiting from do_signal(), so I'll submit that up for 2.6.37 shortly.
> FWIW, I'd do that in handle_signal() when hitting a syscall restart.

Right now I'm just doing it unconditionally in handle_signal()'s caller
whether or not I actually call handle_signal, to be paranoid:

@@ -353,11 +353,11 @@
* clear the TS_RESTORE_SIGMASK flag.
current_thread_info()->status &= ~TS_RESTORE_SIGMASK;

- return;
+ goto done;

/* Did we come from a system call? */
if (regs->faultnum == INT_SWINT_1) {
/* Restart the system call - no handlers present */
@@ -381,10 +381,14 @@
/* If there's no signal to deliver, just put the saved sigmask back. */
if (current_thread_info()->status & TS_RESTORE_SIGMASK) {
current_thread_info()->status &= ~TS_RESTORE_SIGMASK;
sigprocmask(SIG_SETMASK, &current->saved_sigmask, NULL);
+ /* Avoid double syscall restart if there are nested signals. */
+ regs->faultnum = INT_SWINT_1_SIGRETURN;

> BTW, is everything in your pt_regs safe to modify?

What an interesting observation. :-) In fact, it would be possible to
overwrite the privilege level (the ex1 register) from within the signal
handler and then return to run arbitrary code at kernel PL. I'll fix it.

Chris Metcalf, Tilera Corp.

 \ /
  Last update: 2010-10-28 00:53    [W:0.098 / U:2.588 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site