[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADkTA4Oh5+fTEqpNFJjPOfTYhiVQEdUO4Cx2LXpPyPfO+96X1w@mail.gmail.com>
Date: Tue, 8 Oct 2019 08:58:47 -0400
From: Bruce Ashfield <bruce.ashfield@...il.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Roman Gushchin <guro@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"tj@...nel.org" <tj@...nel.org>,
Richard Purdie <richard.purdie@...uxfoundation.org>
Subject: Re: ptrace/strace and freezer oddities and v5.2+ kernels
On Tue, Oct 8, 2019 at 8:36 AM Oleg Nesterov <oleg@...hat.com> wrote:
>
> On 10/08, Bruce Ashfield wrote:
> >
> > So I've been looking through the config delta's and late last night, I was
> > able to move the runtime back to a failed 4 minute state by adding the
> > CONFIG_PREEMPT settings that we have by default in our reference
> > kernel.
>
> Aha... Can you try the patch below?
Confirmed. 4 second runtime with that change, 4 minutes with it in the
original position.
.. I'm kind of shocked I just didn't try that myself, since I spent
plenty of time staring
at the innards of cgroup_enter_frozen() for enough time to at least
get an inkling
to try that.
I'll run this through some additional testing, but initial results are
good. I'm not
familiar enough with the semantics at play to even guess at any
possible side effects.
But do let me know if i can do anything else on this .. and thanks for
everyone's
patience.
Bruce
>
> Oleg.
>
> --- x/kernel/signal.c
> +++ x/kernel/signal.c
> @@ -2205,8 +2205,8 @@ static void ptrace_stop(int exit_code, int why, int clear_code, kernel_siginfo_t
> */
> preempt_disable();
> read_unlock(&tasklist_lock);
> - preempt_enable_no_resched();
> cgroup_enter_frozen();
> + preempt_enable_no_resched();
> freezable_schedule();
> cgroup_leave_frozen(true);
> } else {
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
Powered by blists - more mailing lists