On Thu, Jun 07, 2007 at 01:29:23PM +1000, Benjamin Herrenschmidt wrote:
> But you use ptrace and don't steal signals with dequeue_signal() on a
> live other task, which is ok.
True. However, with an SMP UML running a threaded app (which is also
threads on the host), if the thread on one CPU gets
On Thu, Jun 07, 2007 at 01:29:23PM +1000, Benjamin Herrenschmidt wrote:
But you use ptrace and don't steal signals with dequeue_signal() on a
live other task, which is ok.
True. However, with an SMP UML running a threaded app (which is also
threads on the host), if the thread on one CPU gets a
On Wed, 2007-06-06 at 22:20 -0400, Jeff Dike wrote:
> On Thu, Jun 07, 2007 at 08:43:42AM +1000, Paul Mackerras wrote:
> > What Ben was talking about was stealing a synchronous SEGV from a task
> > without stopping it, and as Ben says that makes no sense.
> > Intercepting a signal and stopping the
On Wed, 2007-06-06 at 08:52 -0400, Jeff Dike wrote:
> On Wed, Jun 06, 2007 at 12:50:04PM +1000, Benjamin Herrenschmidt wrote:
> > Yeah, synchronous signals should probably never be delivered to another
> > process, even via signalfd. There's no point delivering a SEGV to
> > somebody else :-)
>
>
On Thu, Jun 07, 2007 at 08:43:42AM +1000, Paul Mackerras wrote:
> What Ben was talking about was stealing a synchronous SEGV from a task
> without stopping it, and as Ben says that makes no sense.
> Intercepting a signal and stopping the task is reasonable, and that is
> what ptrace does, and I
Jeff Dike writes:
> On Wed, Jun 06, 2007 at 12:50:04PM +1000, Benjamin Herrenschmidt wrote:
> > Yeah, synchronous signals should probably never be delivered to another
> > process, even via signalfd. There's no point delivering a SEGV to
> > somebody else :-)
>
> Sure there is. UML does exactly
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-06-05 at 20:37 -0700, Linus Torvalds wrote:
>
> > I agree that it would be a limitation, but it would be a sane one.
> >
> > How about we try to live with that limitation, if only to avoid the issue
> > of having the private
On Wed, Jun 06, 2007 at 12:50:04PM +1000, Benjamin Herrenschmidt wrote:
> Yeah, synchronous signals should probably never be delivered to another
> process, even via signalfd. There's no point delivering a SEGV to
> somebody else :-)
Sure there is. UML does exactly that - intercepting child
On Tue, 2007-06-05 at 20:37 -0700, Linus Torvalds wrote:
> I agree that it would be a limitation, but it would be a sane one.
>
> How about we try to live with that limitation, if only to avoid the issue
> of having the private signals being stolen by anybody else. If we actually
> find a
On Tue, 2007-06-05 at 20:37 -0700, Linus Torvalds wrote:
I agree that it would be a limitation, but it would be a sane one.
How about we try to live with that limitation, if only to avoid the issue
of having the private signals being stolen by anybody else. If we actually
find a real-live
On Wed, Jun 06, 2007 at 12:50:04PM +1000, Benjamin Herrenschmidt wrote:
Yeah, synchronous signals should probably never be delivered to another
process, even via signalfd. There's no point delivering a SEGV to
somebody else :-)
Sure there is. UML does exactly that - intercepting child signals
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
On Tue, 2007-06-05 at 20:37 -0700, Linus Torvalds wrote:
I agree that it would be a limitation, but it would be a sane one.
How about we try to live with that limitation, if only to avoid the issue
of having the private signals being
Jeff Dike writes:
On Wed, Jun 06, 2007 at 12:50:04PM +1000, Benjamin Herrenschmidt wrote:
Yeah, synchronous signals should probably never be delivered to another
process, even via signalfd. There's no point delivering a SEGV to
somebody else :-)
Sure there is. UML does exactly that -
On Thu, Jun 07, 2007 at 08:43:42AM +1000, Paul Mackerras wrote:
What Ben was talking about was stealing a synchronous SEGV from a task
without stopping it, and as Ben says that makes no sense.
Intercepting a signal and stopping the task is reasonable, and that is
what ptrace does, and I assume
On Wed, 2007-06-06 at 08:52 -0400, Jeff Dike wrote:
On Wed, Jun 06, 2007 at 12:50:04PM +1000, Benjamin Herrenschmidt wrote:
Yeah, synchronous signals should probably never be delivered to another
process, even via signalfd. There's no point delivering a SEGV to
somebody else :-)
Sure
On Wed, 2007-06-06 at 22:20 -0400, Jeff Dike wrote:
On Thu, Jun 07, 2007 at 08:43:42AM +1000, Paul Mackerras wrote:
What Ben was talking about was stealing a synchronous SEGV from a task
without stopping it, and as Ben says that makes no sense.
Intercepting a signal and stopping the task is
On Tue, 5 Jun 2007, Linus Torvalds wrote:
> On Tue, 5 Jun 2007, Davide Libenzi wrote:
> > On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> > >
> > > Yeah, synchronous signals should probably never be delivered to another
> > > process, even via signalfd. There's no point delivering a SEGV to
> a) Process-global signals can be read by any thread (inside or outside
> of the process receiving the signal).
>
> Rationale:
> This should always work, so there's no reason to limit it.
I agree, with an appropriate fix to recalc_sigpending_tsk() to only
clear TIF_SIGPENDING if tsk ==
On Tue, 2007-06-05 at 20:37 -0700, Linus Torvalds wrote:
>
> On Tue, 5 Jun 2007, Davide Libenzi wrote:
> > On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> > >
> > > Yeah, synchronous signals should probably never be delivered to another
> > > process, even via signalfd. There's no point
> That'd be a limitation. Like you can choose to not handle SEGV, you can
> choose to have a signalfd listening to it. Of course, not with the
> intention to *handle* the signal, but with a notification intent.
Hrm.. either you handle it or you are dead ... I fail to see how
signalfd can sneak
On Tue, 5 Jun 2007, Davide Libenzi wrote:
> On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> >
> > Yeah, synchronous signals should probably never be delivered to another
> > process, even via signalfd. There's no point delivering a SEGV to
> > somebody else :-)
>
> That'd be a limitation.
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-06-05 at 17:58 -0700, Nicholas Miell wrote:
> >
> > "At the time of generation, a determination shall be made whether the
> > signal has been generated for the process or for a specific thread
> > within the process. Signals which
On Tue, 2007-06-05 at 17:58 -0700, Nicholas Miell wrote:
>
> "At the time of generation, a determination shall be made whether the
> signal has been generated for the process or for a specific thread
> within the process. Signals which are generated by some action
> attributable to a particular
On Tue, 2007-06-05 at 17:37 -0700, Davide Libenzi wrote:
> On Tue, 5 Jun 2007, Nicholas Miell wrote:
>
> > On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
> > > On Tue, 5 Jun 2007, Nicholas Miell wrote:
> > >
> > > > Yes, that's certainly wrong, but that's an implementation issue. I was
On Tue, 5 Jun 2007, Nicholas Miell wrote:
> On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
> > On Tue, 5 Jun 2007, Nicholas Miell wrote:
> >
> > > Yes, that's certainly wrong, but that's an implementation issue. I was
> > > more concerned about the design of the API.
> > >
> > >
On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
> On Tue, 5 Jun 2007, Nicholas Miell wrote:
>
> > Yes, that's certainly wrong, but that's an implementation issue. I was
> > more concerned about the design of the API.
> >
> > Naively, I would expect a reads on a signalfd to return either
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-06-05 at 15:50 -0700, Davide Libenzi wrote:
> > > What about the code in __dequeue_signal though ? That notifier thing
> > is
> > > used by the DRI though I'm not sure what would happen if it acts on
> > the
> > > wrong task.
> >
>
On Tue, 5 Jun 2007, Nicholas Miell wrote:
> Yes, that's certainly wrong, but that's an implementation issue. I was
> more concerned about the design of the API.
>
> Naively, I would expect a reads on a signalfd to return either process
> signals or thread signals targeted towards the thread
On Tue, 2007-06-05 at 16:51 -0700, Nicholas Miell wrote:
> Yes, that's certainly wrong, but that's an implementation issue. I was
> more concerned about the design of the API.
>
> Naively, I would expect a reads on a signalfd to return either process
> signals or thread signals targeted towards
On Tue, 2007-06-05 at 17:27 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-06-04 at 23:09 -0700, Nicholas Miell wrote:
> > signalfd() doesn't deliver thread-targeted signals to the wrong
> > threads,
> > does it?
> >
> > Hmm.
> >
> > It looks like reading from a signalfd will give you
On Tue, 2007-06-05 at 15:50 -0700, Davide Libenzi wrote:
> > What about the code in __dequeue_signal though ? That notifier thing
> is
> > used by the DRI though I'm not sure what would happen if it acts on
> the
> > wrong task.
>
> Hmm, looking at the comments in block_all_signals(), it seems
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-06-05 at 08:52 -0700, Davide Libenzi wrote:
> > if (tsk == current)
> > recalc_sigpending();
> >
> > What can happen, is that a task may notice TIF_SIGPENDING and not find
> > a
> > signal once it calls
On Tue, 2007-06-05 at 08:52 -0700, Davide Libenzi wrote:
> if (tsk == current)
> recalc_sigpending();
>
> What can happen, is that a task may notice TIF_SIGPENDING and not find
> a
> signal once it calls dequeue_signal(), but this is fine as far as
> signalfd
> goes.
On Tue, 5 Jun 2007, Benjamin Herrenschmidt wrote:
> We don't actually call recalc_sigpending_tsk() when sending a signal to
> some other task, we just set the flag... so I need to recheck my theory
> here about recalc_sigpending_tsk being called for somebody else...
> Something is doing it
On Mon, 2007-06-04 at 23:09 -0700, Nicholas Miell wrote:
> signalfd() doesn't deliver thread-targeted signals to the wrong
> threads,
> does it?
>
> Hmm.
>
> It looks like reading from a signalfd will give you either
> process-global signals or the thread-specific signals that are
> targeted
>
On Tue, 2007-06-05 at 13:22 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-06-04 at 19:38 -0700, Davide Libenzi wrote:
> > > - I still think there's something wrong with dequeue_signal() being
> > > potentially called with a task different than current by signalfd, since
> > >
On Tue, 2007-06-05 at 13:22 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2007-06-04 at 19:38 -0700, Davide Libenzi wrote:
- I still think there's something wrong with dequeue_signal() being
potentially called with a task different than current by signalfd, since
__dequeue_signal()
On Mon, 2007-06-04 at 23:09 -0700, Nicholas Miell wrote:
signalfd() doesn't deliver thread-targeted signals to the wrong
threads,
does it?
Hmm.
It looks like reading from a signalfd will give you either
process-global signals or the thread-specific signals that are
targeted
towards the
On Tue, 5 Jun 2007, Benjamin Herrenschmidt wrote:
We don't actually call recalc_sigpending_tsk() when sending a signal to
some other task, we just set the flag... so I need to recheck my theory
here about recalc_sigpending_tsk being called for somebody else...
Something is doing it somewhere
On Tue, 2007-06-05 at 08:52 -0700, Davide Libenzi wrote:
if (tsk == current)
recalc_sigpending();
What can happen, is that a task may notice TIF_SIGPENDING and not find
a
signal once it calls dequeue_signal(), but this is fine as far as
signalfd
goes. This should
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
On Tue, 2007-06-05 at 08:52 -0700, Davide Libenzi wrote:
if (tsk == current)
recalc_sigpending();
What can happen, is that a task may notice TIF_SIGPENDING and not find
a
signal once it calls
On Tue, 2007-06-05 at 15:50 -0700, Davide Libenzi wrote:
What about the code in __dequeue_signal though ? That notifier thing
is
used by the DRI though I'm not sure what would happen if it acts on
the
wrong task.
Hmm, looking at the comments in block_all_signals(), it seems that
On Tue, 2007-06-05 at 17:27 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2007-06-04 at 23:09 -0700, Nicholas Miell wrote:
signalfd() doesn't deliver thread-targeted signals to the wrong
threads,
does it?
Hmm.
It looks like reading from a signalfd will give you either
On Tue, 2007-06-05 at 16:51 -0700, Nicholas Miell wrote:
Yes, that's certainly wrong, but that's an implementation issue. I was
more concerned about the design of the API.
Naively, I would expect a reads on a signalfd to return either process
signals or thread signals targeted towards the
On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
On Tue, 5 Jun 2007, Nicholas Miell wrote:
Yes, that's certainly wrong, but that's an implementation issue. I was
more concerned about the design of the API.
Naively, I would expect a reads on a signalfd to return either process
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
On Tue, 2007-06-05 at 15:50 -0700, Davide Libenzi wrote:
What about the code in __dequeue_signal though ? That notifier thing
is
used by the DRI though I'm not sure what would happen if it acts on
the
wrong task.
Hmm, looking at
On Tue, 5 Jun 2007, Nicholas Miell wrote:
Yes, that's certainly wrong, but that's an implementation issue. I was
more concerned about the design of the API.
Naively, I would expect a reads on a signalfd to return either process
signals or thread signals targeted towards the thread doing the
On Tue, 5 Jun 2007, Nicholas Miell wrote:
On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
On Tue, 5 Jun 2007, Nicholas Miell wrote:
Yes, that's certainly wrong, but that's an implementation issue. I was
more concerned about the design of the API.
Naively, I would
On Tue, 2007-06-05 at 17:37 -0700, Davide Libenzi wrote:
On Tue, 5 Jun 2007, Nicholas Miell wrote:
On Tue, 2007-06-05 at 17:11 -0700, Davide Libenzi wrote:
On Tue, 5 Jun 2007, Nicholas Miell wrote:
Yes, that's certainly wrong, but that's an implementation issue. I was
more
On Tue, 2007-06-05 at 17:58 -0700, Nicholas Miell wrote:
At the time of generation, a determination shall be made whether the
signal has been generated for the process or for a specific thread
within the process. Signals which are generated by some action
attributable to a particular thread,
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
On Tue, 2007-06-05 at 17:58 -0700, Nicholas Miell wrote:
At the time of generation, a determination shall be made whether the
signal has been generated for the process or for a specific thread
within the process. Signals which are
On Tue, 5 Jun 2007, Davide Libenzi wrote:
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
Yeah, synchronous signals should probably never be delivered to another
process, even via signalfd. There's no point delivering a SEGV to
somebody else :-)
That'd be a limitation. Like you
That'd be a limitation. Like you can choose to not handle SEGV, you can
choose to have a signalfd listening to it. Of course, not with the
intention to *handle* the signal, but with a notification intent.
Hrm.. either you handle it or you are dead ... I fail to see how
signalfd can sneak in
On Tue, 2007-06-05 at 20:37 -0700, Linus Torvalds wrote:
On Tue, 5 Jun 2007, Davide Libenzi wrote:
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
Yeah, synchronous signals should probably never be delivered to another
process, even via signalfd. There's no point delivering a SEGV
a) Process-global signals can be read by any thread (inside or outside
of the process receiving the signal).
Rationale:
This should always work, so there's no reason to limit it.
I agree, with an appropriate fix to recalc_sigpending_tsk() to only
clear TIF_SIGPENDING if tsk ==
On Tue, 5 Jun 2007, Linus Torvalds wrote:
On Tue, 5 Jun 2007, Davide Libenzi wrote:
On Wed, 6 Jun 2007, Benjamin Herrenschmidt wrote:
Yeah, synchronous signals should probably never be delivered to another
process, even via signalfd. There's no point delivering a SEGV to
somebody
On Mon, 2007-06-04 at 19:38 -0700, Davide Libenzi wrote:
> > - I still think there's something wrong with dequeue_signal() being
> > potentially called with a task different than current by signalfd, since
> > __dequeue_signal() (among others) mucks around with current regardless.
> > I'd love to
On Tue, 5 Jun 2007, Benjamin Herrenschmidt wrote:
> - I still think there's something wrong with dequeue_signal() being
> potentially called with a task different than current by signalfd, since
> __dequeue_signal() (among others) mucks around with current regardless.
> I'd love to just make
> >
> > - something calls recalc_sigpending_tsk() on thread A (for example,
> >something try to sends it S2 which is blocked). There is no longer
> >an active signal and thus TIF_SIGPENDING is cleared on thread A
>
> I agree. That's unquestionably a bug. We should *never* clear
On Tue, 5 Jun 2007, Benjamin Herrenschmidt wrote:
>
> - something calls recalc_sigpending_tsk() on thread A (for example,
>something try to sends it S2 which is blocked). There is no longer
>an active signal and thus TIF_SIGPENDING is cleared on thread A
I agree. That's unquestionably
The story starts with...
We've been seeing some occasional reports of -ERESTARTSYS and friends
being returned to userland from syscalls like accept(). After some
digging, we beleive that the signal code is inherently racy vs. the
way one task (or interrupt) can cause another task TIG_SIGPENDING
The story starts with...
We've been seeing some occasional reports of -ERESTARTSYS and friends
being returned to userland from syscalls like accept(). After some
digging, we beleive that the signal code is inherently racy vs. the
way one task (or interrupt) can cause another task TIG_SIGPENDING
On Tue, 5 Jun 2007, Benjamin Herrenschmidt wrote:
- something calls recalc_sigpending_tsk() on thread A (for example,
something try to sends it S2 which is blocked). There is no longer
an active signal and thus TIF_SIGPENDING is cleared on thread A
I agree. That's unquestionably a
- something calls recalc_sigpending_tsk() on thread A (for example,
something try to sends it S2 which is blocked). There is no longer
an active signal and thus TIF_SIGPENDING is cleared on thread A
I agree. That's unquestionably a bug. We should *never* clear sigpending
for
On Tue, 5 Jun 2007, Benjamin Herrenschmidt wrote:
- I still think there's something wrong with dequeue_signal() being
potentially called with a task different than current by signalfd, since
__dequeue_signal() (among others) mucks around with current regardless.
I'd love to just make
On Mon, 2007-06-04 at 19:38 -0700, Davide Libenzi wrote:
- I still think there's something wrong with dequeue_signal() being
potentially called with a task different than current by signalfd, since
__dequeue_signal() (among others) mucks around with current regardless.
I'd love to just
66 matches
Mail list logo
