[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200721153823.GA28364@redhat.com>
Date: Tue, 21 Jul 2020 17:38:24 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: peterz@...radead.org
Cc: Paul Gortmaker <paul.gortmaker@...driver.com>,
Jiri Slaby <jirislaby@...nel.org>,
Christian Brauner <christian.brauner@...ntu.com>,
christian@...uner.io, "Eric W. Biederman" <ebiederm@...ssion.com>,
Linux kernel mailing list <linux-kernel@...r.kernel.org>,
Mel Gorman <mgorman@...e.de>,
Dave Jones <davej@...emonkey.org.uk>
Subject: Re: [PATCH] sched: Fix race against ptrace_freeze_trace()
On 07/21, Peter Zijlstra wrote:
>
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4193,9 +4193,6 @@ static void __sched notrace __schedule(b
> local_irq_disable();
> rcu_note_context_switch(preempt);
>
> - /* See deactivate_task() below. */
> - prev_state = prev->state;
> -
> /*
> * Make sure that signal_pending_state()->signal_pending() below
> * can't be reordered with __set_current_state(TASK_INTERRUPTIBLE)
> @@ -4219,11 +4216,16 @@ static void __sched notrace __schedule(b
> update_rq_clock(rq);
>
> switch_count = &prev->nivcsw;
> +
> /*
> - * We must re-load prev->state in case ttwu_remote() changed it
> - * before we acquired rq->lock.
> + * We must load prev->state once (task_struct::state is volatile), such
> + * that:
> + *
> + * - we form a control dependency vs deactivate_task() below.
> + * - ptrace_{,un}freeze_traced() can change ->state underneath us.
> */
> - if (!preempt && prev_state && prev_state == prev->state) {
> + prev_state = prev->state;
> + if (!preempt && prev_state) {
Thanks! FWIW,
Acked-by: Oleg Nesterov <oleg@...hat.com>
Powered by blists - more mailing lists