Oh.
In any event, we don't want to ignore the SIGSTOP. We want the thread
to
quiesce (so it can be debugged), but we don't want to have to leave the
ioctl
(and lose state).
It's increasingly clear that the Right Thing To Do is to redesign the
driver
so that it spends less time in the kernel and can restart any ioctls
that are
interrupted by SIGSTOPs without losing track of where it was in its
conversation with the device. This is going to be more complex and
less
efficient (more privilege switching) than what we presently have, and
I'm
trying hard to understand exactly why it's the Right Thing To Do.
>From a logical (if naive) point of view, SIGSTOP simply changes the run
state
of the target (doesn't it?) and in principle I would have thought it
could
manage to do so without having to muck with any other piece of the
target's
state. Given that (whether for aesthetic or practical reasons or both)
the
kernel has to fiddle with the target's state to get it out of the sleep,
once
that's done the SIGSTOP has accomplished its objective (hasn't it?), so
if a
subsequent SIGCONT comes in and the driver simply goes back to what it
was
doing before it was stopped, what exactly has been "lost"?
Richard Henderson wrote:
>
> On Fri, Aug 18, 2000 at 05:48:14PM -0400, Jonathan Edwards wrote:
> > Does this look reasonable, or are we setting ourselves up for disaster?
> >
> > again:
> > interruptible_sleep_on(&q)
> >
> > // Ignore SIGSTOP (generated if invoking process is under debug...)
> > if (sigismember(&(current->signal),SIGSTOP))
> > {
> > sigdelset(&(current->signal),SIGSTOP);
> > recalc_sigpending(current);
> > goto again;
> > }
>
> You've now lost the SIGSTOP entirely.
>
> You're better off blocking the signal before the interruptible_sleep_on
> and unblocking it afterwards, just as you would from userland when you
> don't want to see a particular signal.
>
> r~
>> SIGSTOP can't be blocked.
>
>Userland can't block SIGSTOP. The kernel most certainly can.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo _at_ vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/