[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 6 Jun 2023 13:04:48 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH REPOST 2/2] signal: Don't disable preemption in
ptrace_stop() on PREEMPT_RT.
The patch LGTM, but I am a bit confused by the changelog/comments,
I guess I missed something...
On 06/06, Sebastian Andrzej Siewior wrote:
>
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -2328,11 +2328,16 @@ static int ptrace_stop(int exit_code, int why, unsigned long message,
> * The preempt-disable section ensures that there will be no preemption
> * between unlock and schedule() and so improving the performance since
> * the ptracer has no reason to sleep.
> + *
> + * This optimisation is not doable on PREEMPT_RT due to the spinlock_t
> + * within the preempt-disable section.
> */
> - preempt_disable();
> + if (!IS_ENABLED(CONFIG_PREEMPT_RT))
> + preempt_disable();
Not only we the problems with cgroup_enter_frozen(), afaics (please correct me)
this optimisation doesn't work on RT anyway?
IIUC, read_lock() on RT disables migration but not preemption, so it is simply
too late to do preempt_disable() before unlock/schedule. The tracer can preempt
the tracee right after do_notify_parent_cldstop().
Oleg.
Powered by blists - more mailing lists