Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Eric W. Biederman" <ebiederm@xmission.com>
To:     Sven Schnelle <svens@linux.ibm.com>
Cc:     Oleg Nesterov <oleg@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Alexander Gordeev <agordeev@linux.ibm.com>,
        Kees Cook <keescook@chromium.org>, linux-kernel@vger.kernel.org
References: <20220706101625.2100298-1-svens@linux.ibm.com>
Date:   Wed, 06 Jul 2022 16:15:17 -0500
In-Reply-To: <20220706101625.2100298-1-svens@linux.ibm.com> (Sven Schnelle's
        message of "Wed, 6 Jul 2022 12:16:25 +0200")
Message-ID: <87k08qlz8a.fsf@email.froward.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PATCH] ptrace: fix clearing of JOBCTL_TRACED in
 ptrace_unfreeze_traced()
Precedence: bulk

Sven Schnelle <svens@linux.ibm.com> writes:

> CI reported the following splat while running the strace testsuite:
>
> [ 3976.640309] WARNING: CPU: 1 PID: 3570031 at kernel/ptrace.c:272 ptrace_check_attach+0x12e/0x178
> [ 3976.640391] CPU: 1 PID: 3570031 Comm: strace Tainted: G           OE     5.19.0-20220624.rc3.git0.ee819a77d4e7.300.fc36.s390x #1
> [ 3976.640410] Hardware name: IBM 3906 M04 704 (z/VM 7.1.0)
> [ 3976.640452] Call Trace:
> [ 3976.640454]  [<00000000ab4b645a>] ptrace_check_attach+0x132/0x178
> [ 3976.640457] ([<00000000ab4b6450>] ptrace_check_attach+0x128/0x178)
> [ 3976.640460]  [<00000000ab4b6cde>] __s390x_sys_ptrace+0x86/0x160
> [ 3976.640463]  [<00000000ac03fcec>] __do_syscall+0x1d4/0x200
> [ 3976.640468]  [<00000000ac04e312>] system_call+0x82/0xb0
> [ 3976.640470] Last Breaking-Event-Address:
> [ 3976.640471]  [<00000000ab4ea3c8>] wait_task_inactive+0x98/0x190
>
> This is because JOBCTL_TRACED is set, but the task is not in TASK_TRACED
> state. Caused by ptrace_unfreeze_traced() which does:
>
> task->jobctl &= ~TASK_TRACED
>
> but it should be:
>
> task->jobctl &= ~JOBCTL_TRACED


That would definitely do it.  I had to think about it for a few minutes
to see how it explains some of the stranger behavior but it explains
all of the funny behavior I have seen.

Thank you for tracking this down.

The fact the original bug report was on s390 had me somehow thinking
this was s390 only.

I will double check everything get this in linux-next and then send this
to Linus.

Eric


> Fixes: 31cae1eaae4f ("sched,signal,ptrace: Rework TASK_TRACED, TASK_STOPPED state")
> Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
> ---
>  kernel/ptrace.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index 156a99283b11..1893d909e45c 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -222,7 +222,7 @@ static void ptrace_unfreeze_traced(struct task_struct *task)
>  	if (lock_task_sighand(task, &flags)) {
>  		task->jobctl &= ~JOBCTL_PTRACE_FROZEN;
>  		if (__fatal_signal_pending(task)) {
> -			task->jobctl &= ~TASK_TRACED;
> +			task->jobctl &= ~JOBCTL_TRACED;
>  			wake_up_state(task, __TASK_TRACED);
>  		}
>  		unlock_task_sighand(task, &flags);