All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: peterz@infradead.org
Cc: Oleg Nesterov <oleg@redhat.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	Christian Brauner <christian.brauner@ubuntu.com>,
	christian@brauner.io, "Eric W. Biederman" <ebiederm@xmission.com>,
	Linux kernel mailing list <linux-kernel@vger.kernel.org>,
	Mel Gorman <mgorman@suse.de>,
	Dave Jones <davej@codemonkey.org.uk>,
	Paul Gortmaker <paul.gortmaker@windriver.com>
Subject: Re: 5.8-rc*: kernel BUG at kernel/signal.c:1917
Date: Mon, 20 Jul 2020 15:26:16 +0100	[thread overview]
Message-ID: <jhjv9iii7p3.mognet@arm.com> (raw)
In-Reply-To: <20200720131747.GD119549@hirez.programming.kicks-ass.net>


On 20/07/20 14:17, peterz@infradead.org wrote:
> On Mon, Jul 20, 2020 at 01:20:26PM +0100, Valentin Schneider wrote:
>> On 20/07/20 12:26, peterz@infradead.org wrote:
>
>> > +	/*
>> > +	 * We must re-load prev->state in case ttwu_remote() changed it
>> > +	 * before we acquired rq->lock.
>> > +	 */
>> > +	tmp_state = prev->state;
>> > +	if (unlikely(prev_state != tmp_state)) {
>> > +		/*
>> > +		 * ptrace_{,un}freeze_traced() think it is cool to change
>> > +		 * ->state around behind our backs between TASK_TRACED and
>> > +		 *  __TASK_TRACED.
>> > +		 *
>> > +		 * This is safe because this, as well as any __TASK_TRACED
>> > +		 * wakeups are under siglock.
>> > +		 *
>> > +		 * For any other case, a changed prev_state must be to
>> > +		 * TASK_RUNNING, such that when it blocks, the load has
>> > +		 * happened before the smp_mb().
>> > +		 *
>> > +		 * Also see the comment with deactivate_task().
>> > +		 */
>> > +		SCHED_WARN_ON(tmp_state && (prev_state & __TASK_TRACED &&
>> > +					   !(tmp_state & __TASK_TRACED)));
>> > +
>>
>> IIUC if the state changed and isn't TASK_RUNNING it *has* to have
>> __TASK_TRACED, so can't that be
>>
>>   SCHED_WARN_ON(tmp_state && !(tmp_state & __TASK_TRACED));
>
> Suppose task->state == TASK_UNINTERRUPTIBLE, and task != current, and
> then someone goes and does task->state = __TASK_TRACED.
>
> That is, your statement is correct given the current code, but we also
> want to verify no new code comes along and does something 'creative'.
>

That is what I was trying to go for; AFAICT your approach only warns if
__TASK_TRACED gets removed between the two loads (IOW it was already
there). The way I was seeing it is:

- We only get here if prev_state != tmp_state; IOW we know we raced with
  something
- if (tmp_state), then it wasn't with ttwu_remote()
- thus it must only be with ptrace shenanigans, IOW __TASK_TRACED must be
  there.

Now, what I suggested still doesn't detect what you pointed out, or some
crazier thing that sets __TASK_TRACED *and* some other stuff. IIUC the
ptrace transformation does TASK_TRACED -> __TASK_TRACED, so we could have
it as:

  /* TODO: name me */
  #define foobar TASK_TRACED ^ __TASK_TRACED

  ...

  /* not TASK_RUNNING; check against allowed transformations
  SCHED_WARN_ON(tmp_state && ((prev_state ^ tmp_state) & ~foobar));


That said...

> Or is the heat getting to me?

... that may apply to me as well :-)

  reply	other threads:[~2020-07-20 14:26 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-17 10:45 5.8-rc*: kernel BUG at kernel/signal.c:1917 Jiri Slaby
2020-07-17 11:04 ` Jiri Slaby
2020-07-17 11:12   ` Christian Brauner
2020-07-18 13:05     ` Jiri Slaby
2020-07-17 12:26   ` Oleg Nesterov
2020-07-17 12:40     ` Oleg Nesterov
2020-07-18 12:28       ` Jiri Slaby
2020-07-18 17:14         ` Oleg Nesterov
2020-07-18 17:44           ` Christian Brauner
2020-07-20  5:44             ` Jiri Slaby
2020-07-20  6:43               ` Oleg Nesterov
2020-07-20  8:26                 ` Oleg Nesterov
2020-07-20  8:41                   ` Peter Zijlstra
2020-07-20 10:59                     ` peterz
2020-07-20 11:26                       ` peterz
2020-07-20 11:40                         ` Jiri Slaby
2020-07-20 12:20                         ` Valentin Schneider
2020-07-20 13:17                           ` peterz
2020-07-20 14:26                             ` Valentin Schneider [this message]
2020-07-20 12:57                         ` Christian Brauner
2020-07-20 14:05                         ` peterz
2020-07-20 14:02                       ` Oleg Nesterov
2020-07-20 14:21                         ` Peter Zijlstra
2020-07-20 14:39                           ` Oleg Nesterov
2020-07-20 15:35                             ` Oleg Nesterov
2020-07-20 15:38                               ` Peter Zijlstra
2020-07-21  4:52                           ` Paul Gortmaker
2020-07-21  8:37                             ` peterz
2020-07-21 12:13                               ` [PATCH] sched: Fix race against ptrace_freeze_trace() peterz
2020-07-21 14:29                                 ` Christian Brauner
2020-07-21 15:38                                 ` Oleg Nesterov
2020-07-21  9:14                           ` 5.8-rc*: kernel BUG at kernel/signal.c:1917 Valentin Schneider
     [not found]           ` <20200719072726.5892-1-hdanton@sina.com>
2020-07-19 18:23             ` Oleg Nesterov
2020-07-20  6:00           ` Jiri Slaby
2020-07-20  6:56             ` Oleg Nesterov

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=jhjv9iii7p3.mognet@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=christian@brauner.io \
    --cc=davej@codemonkey.org.uk \
    --cc=ebiederm@xmission.com \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=oleg@redhat.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=peterz@infradead.org \
    /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.