All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Andrew Vagin <avagin@parallels.com>
Cc: Andrey Vagin <avagin@openvz.org>,
	linux-kernel@vger.kernel.org, Roland McGrath <roland@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Pavel Emelyanov <xemul@parallels.com>,
	Cyrill Gorcunov <gorcunov@openvz.org>
Subject: Re: [PATCH] ptrace: add ability to get/set signal-blocked mask
Date: Tue, 23 Apr 2013 15:11:51 +0200	[thread overview]
Message-ID: <20130423131151.GA23924@redhat.com> (raw)
In-Reply-To: <20130423105917.GA11121@paralelels.com>

On 04/23, Andrew Vagin wrote:
>
> On Mon, Apr 22, 2013 at 05:07:10PM +0200, Oleg Nesterov wrote:
>
> > >
> > > I don't understand "This method is not suitable for stopped tasks"
>
> For example, a stopped process has a pending signal and this signal is
> not blocked. crtools should dump its state,

Ah, thanks, I thought that you meant restoring doesn't work...

> > > from the changelog, but if you really need PTRACE_SETSIGMASK just
> > > change ->blocked under siglock and do recalc_sigpending_tsk(child).
> >                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > actually this is not necessary, the tracee will do recalc_sigpending()
> > after resume. But perhaps a comment make sense.
>
> __set_task_blocked executes retarget_shared_pending. I think it must be
> called here too or am I wrong?

Yes sure, this is the main reason why set_current_blocked() exists.
We do not want to "delay" a group-wide signal.

But ptrace can delay it anyway? And, assuming that other threads are
stopped too this all doesn't matter at all, every thread does
recalc_sigpending() after resume. In short, if the debugger blocks a
signal, it should know what it does.

IOW, I hope this is not a problem, and I'd like to avoid the usage of
__set_task_blocked outside of signal.c or with tsk != current.

Oleg.


      reply	other threads:[~2013-04-23 13:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-22  9:53 [PATCH] ptrace: add ability to get/set signal-blocked mask Andrey Vagin
     [not found] ` <20130422145704.GA30029@redhat.com>
2013-04-22 15:07   ` Oleg Nesterov
2013-04-23 10:59     ` Andrew Vagin
2013-04-23 13:11       ` Oleg Nesterov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130423131151.GA23924@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=avagin@openvz.org \
    --cc=avagin@parallels.com \
    --cc=gorcunov@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=roland@redhat.com \
    --cc=xemul@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.