mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jerome Marchand <jmarchan@redhat.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] ptrace_untrace: fix the SIGNAL_STOP_STOPPED check
Date: Sun,  8 Feb 2009 19:59:27 -0800 (PST)	[thread overview]
Message-ID: <20090209035927.D35F1FC330@magilla.sf.frob.com> (raw)
In-Reply-To: Oleg Nesterov's message of  Monday, 9 February 2009 04:09:53 +0100 <20090209030953.GA30787@redhat.com>

> Because we have another case. The group stop is in progress, and some
> thread T does do_signal_stop()->finish_stop(). It is TASK_STOPPED.
> Now we do PTRACE_ATTACH + PTRACE_DETACH. And the second sys_ptrace()
> changes T->state to TASK_TRACED.

There is no problem here.  The original TASK_STOPPED and the new
TASK_TRACED count the same as far as group-stop accounting.

> And. It it also possible that we ptrace the single sub-thread, then
> the group stop starts. The first thread which enters do_signal_stop()
> will not count the TASK_TRACED child, so it should stay stopped.

As it will, by checking for group_stop_count || SIGNAL_STOP_STOPPED.

> Perhaps this is just my misunderstanding, but
> 
> 	/*
> 	 * Turn a tracing stop into a normal stop now, since with no tracer there
> 	 * would be no way to wake it up with SIGCONT or SIGKILL.
> 
> This looks as if we always do /TRACED/STOPPED/ unconditionally.

... until you read the next sentence that describes the other case.

> 	                                                           If there was a
> 	 * signal sent that would resume the child, but didn't because it was in
> 	 * TASK_TRACED, resume it now.
> 
> No, we resume it not because it may have signals, and we don't even check
> it has pending signals.

The comment is accurate: it doesn't have anything to do with pending signals.
An ignored SIGCONT "was a signal sent that would resume the child", but is
not pending.  (Likewise a caught SIGCONT already dequeued by another thread.)
SIGNAL_STOP_STOPPED being clear is what indicates that "there was a signal
sent that would resume the child".  (It is prepare_signal() that would have
resumed the task, not any present or past state of pendingness of any signal.)

> 	 * Requires that irqs be disabled.
> 	 */
> 
> this is correct ;)

... too. ;-)

Seriously, feel free to rewrite comments so they are more unambiguous.  
But this one is not incorrect when interpreted as I do (as it was
intended), just apparently ambiguous to some eyes such as yours.
The purpose of comments is to be clear to everyone, so change may be
warranted.  But clarity of unambiguous expression is not found in
interpreting ambiguity as being unambiguously clear and wrong.


Thanks,
Roland

      reply	other threads:[~2009-02-09  3:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-08 18:47 Oleg Nesterov
2009-02-09  1:50 ` Roland McGrath
2009-02-09  3:09   ` Oleg Nesterov
2009-02-09  3:59     ` Roland McGrath [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=20090209035927.D35F1FC330@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dvlasenk@redhat.com \
    --cc=jmarchan@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®