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, 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
32 matches
Mail list logo
