Re: PTRACE_SEIZE should not stop [Re: [PATCH 02/11] ptrace:implement PTRACE_SEIZE]

[Tejun Heo]

Hello,

On Mon, May 16, 2011 at 02:26:42PM +0200, Jan Kratochvil wrote:
> > I can't understand the above sentence.  A thread can't deliver signal
> > without going through tracer while ptraced.  Can you elaborate a bit
> > more?
> 
> I tried to explain why GDB will see SIGUSR1 twice.  Despite it is not
> a realtime signal and therefore the signal is "flag", it does not queue/count.
> You know better than me why GDB sees SIGUSR1 twice.

Ah, okay.  Well, there are five threads sending USR1 and five USR2,
right?  The main thread would enter signal delivery path when the
first signal (be it USR1 or USR2) wakes it up and on dequeueing the
first signal (USR1 here), it would trap for signal delivery.
Depending on timing, this may happen after all signals are generated
but more likely to happen before some of them haven't finished sending
yet.

So, while the first USR1 is being delivered through ptrace and
whatnot, the remaining signals are sent, some of them are USR1, thus
making USR1 pending again.

Once you finish delivering USR1, signal delivery path is restarted and
the new pending USR1 is delivered and then USR2.

> > There's no distinction between main or sub threads in terms of signal
> > delivery unless signal itself is specifically directed to a thread.
> 
> This sample code uses only tkill to avoid any mess with which TID will get
> which signal.

Yeap.  Missed that.

> > Isn't that the signal pending mask?
> 
> Yes but how do you query siginfo_t (GDB $_siginfo) of a pending signal to make
> it accessible to the user?

You can't, at least not yet, but wouldn't presenting list of pending
signals be helpful enough?

> You also need to mask out blocked signals

I thought we export this through /proc.  Maybe not.  I'll check.

> and properly order them like kernel does - which is not guaranteed
> by POSIX.  You need to reimplement part of the kernel functionality
> and if you implement it a bit differently it will break transparency
> of the debugging.

I don't get why the delivery ordering matters.

> > * If there are signals to deliver,
> 
> This is the question if the debugger can reliably detect.  Maybe it can.

This shouldn't be too hard.  You just need to know all the masks.

> >   CONT it and it will take the signal
> >   trap (eventually).  During signal trap, do PTRACE_INTERRUPT and then
> >   let the tracee deliver the signal.  Tracee will deliver the signal
> >   and take STOP trap.
> > 
> > Is the above enough for your use case?
> 
> If there is enough documentation - or one reads the soures - one can
> reimplement the signal delivery login in userland to expect what will kernel
> do.  TBH I do not think it is the right API but you are right it is
> workaroundable in userland.

Oh, I would strongly recomment something like that.  Don't depend on
implementation details.  I still don't understand why you need to know
the order beforehand.  Wouldn't pending list be enough?  What are you
trying to achieve?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/