linux-kernel - Re: ptrace/strace and freezer oddities and v5.2+ kernels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 2 Oct 2019 02:01:06 +0000
From:   Roman Gushchin <guro@...com>
To:     Bruce Ashfield <bruce.ashfield@...il.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "tj@...nel.org" <tj@...nel.org>,
        Richard Purdie <richard.purdie@...uxfoundation.org>,
        "oleg@...hat.com" <oleg@...hat.com>
Subject: Re: ptrace/strace and freezer oddities and v5.2+ kernels

On Tue, Oct 01, 2019 at 12:14:18PM -0400, Bruce Ashfield wrote:
> Hi all,
>

Hi Bruce!

> The Yocto project has an upcoming release this fall, and I've been trying to
> sort through some issues that are happening with kernel 5.2+ .. although
> there is a specific yocto kernel, I'm testing and seeing this with
> normal / vanilla
> mainline kernels as well.
> 
> I'm running into an issue that is *very* similar to the one discussed in the
> [REGRESSION] ptrace broken from "cgroup: cgroup v2 freezer" (76f969e)
> thread from this past may: https://lkml.org/lkml/2019/5/12/272
> 
> I can confirm that I have the proposed fix for the initial regression report in
> my build (05b2892637 [signal: unconditionally leave the frozen state
> in ptrace_stop()]),
> but yet I'm still seeing 3 or 4 minute runtimes on a test that used to take 3 or
> 4 seconds.

So, the problem is that you're experiencing a severe performance regression
in some test, right?

> 
> This isn't my normal area of kernel hacking, so I've so far come up empty
> at either fixing it myself, or figuring out a viable workaround. (well, I can
> "fix" it by remove the cgroup_enter_frozen() call in ptrace_stop ...
> but obviously,
> that is just me trying to figure out what could be causing the issue).
> 
> As part of the release, we run tests that come with various applications. The
> ptrace test that is causing us issues can be boiled down to this:
> 
> $ cd /usr/lib/strace/ptest/tests
> $ time ../strace -o log -qq -esignal=none -e/clock ./printpath-umovestr>ttt
> 
> (I can provide as many details as needed, but I wanted to keep this initial
> email relatively short).
> 
> I'll continue to debug and attempt to fix this myself, but I grabbed the
> email list from the regression report in May to see if anyone has any ideas
> or angles that I haven't covered in my search for a fix.

I'm definitely happy to help, but it's a bit hard to say anything from what
you've provided. I'm not aware of any open issues with the freezer except
some spurious cgroup frozen<->not frozen transitions which can happen in some
cases. If you'll describe how can I reproduce the issue, and I'll try to take
a look asap.

Roman