Bug#963493: Repeatable hard lockup running strace testsuite using 4.19.118+2+deb10u1, 4.19.98+1+deb10u1 works fine

[Steve McIntyre <steve@einval.com>]

OK, so I've just bisected down the stable 4.19.y branch from 4.19.98
to 4.19.118. What I've found is:

e58f543fc7c0926f31a49619c1a3648e49e8d233 is the first bad commit
commit e58f543fc7c0926f31a49619c1a3648e49e8d233
Author: Jann Horn <jannh@google.com>
Date:   Thu Sep 13 18:12:09 2018 +0200

    apparmor: don't try to replace stale label in ptrace access check
    
    [ Upstream commit 1f8266ff58840d698a1e96d2274189de1bdf7969 ]
    
    As a comment above begin_current_label_crit_section() explains,
    begin_current_label_crit_section() must run in sleepable context because
    when label_is_stale() is true, aa_replace_current_label() runs, which uses
    prepare_creds(), which can sleep.
    Until now, the ptrace access check (which runs with a task lock held)
    violated this rule.
    
    Also add a might_sleep() assertion to begin_current_label_crit_section(),
    because asserts are less likely to be ignored than comments.
    
    Fixes: b2d09ae449ced ("apparmor: move ptrace checks to using labels")
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

:040000 040000 ca92f885a38c1747b812116f19de6967084a647e 865a227665e460e159502f21e8a16e6fa590bf50 M security

Considering I'm running strace build tests to provoke this bug,
finding the failure in a commit talking about ptrace changes does look
very suspicious...!

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html