[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220405083445.GA31401@redhat.com>
Date: Tue, 5 Apr 2022 10:34:45 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Ben Segall <bsegall@...gle.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Ingo Molnar <mingo@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>,
Mel Gorman <mgorman@...e.de>,
Peter Zijlstra <peterz@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH v2] ptrace: fix ptrace vs tasklist_lock race on
PREEMPT_RT.
On 04/04, Oleg Nesterov wrote:
>
> Cough. Somehow I can hardly understand v2. For example, if we fix
> wait_task_inactive() correctly, then why ptrace_freeze_traced()
> should take saved_state into account? And how can unfreeze_traced
> hit saved_state == __TASK_TRACED ?
OK, somehow I forgot that ptrace_freeze_traced() is called before
wait_task_inactive(), so it does need to check/change saved_state.
But still, ptrace_unfreeze_traced() can't see task->saved_state ==
__TASK_TRACED, right ?
Oleg.
Powered by blists - more mailing lists