Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S932463AbdLOPwJ (ORCPT <rfc822;w@1wt.eu>);
        Fri, 15 Dec 2017 10:52:09 -0500
Received: from mail.kernel.org ([198.145.29.99]:50800 "EHLO mail.kernel.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932247AbdLOPwG (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 15 Dec 2017 10:52:06 -0500
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D6892190C
Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org
X-Google-Smtp-Source: ACJfBotSj9sONSYtYyGx4UPACGuf4322BBwYbudzMcEmSuUyGf0tEMGbiiARbQkoNOpBXYY6vF2qJdGKBsfIpqqj9ZA=
MIME-Version: 1.0
In-Reply-To: <alpine.LSU.2.21.1712151339490.10847@pobox.suse.cz>
References: <alpine.LSU.2.21.1712151339490.10847@pobox.suse.cz>
From: Andy Lutomirski <luto@kernel.org>
Date: Fri, 15 Dec 2017 07:51:45 -0800
X-Gmail-Original-Message-ID: <CALCETrXUrDXZ_aXC-iaN7757jFSkS0JaFOz2b9rEsVKuNUshyA@mail.gmail.com>
Message-ID: <CALCETrXUrDXZ_aXC-iaN7757jFSkS0JaFOz2b9rEsVKuNUshyA@mail.gmail.com>
Subject: Re: stack traces and zombie tasks
To: Miroslav Benes <mbenes@suse.cz>
Cc: Andrew Lutomirski <luto@kernel.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>, X86 ML <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        live-patching@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1601
Lines: 35

On Fri, Dec 15, 2017 at 4:54 AM, Miroslav Benes <mbenes@suse.cz> wrote:
> Hi,
>
> commit 1959a60182f4 ("x86/dumpstack: Pin the target stack when dumping
> it") slightly changed the behaviour of stack traces dumping for zombie
> tasks.
>
> Before the commit (well, this is older SLE12 kernel, but that should not
> matter), if one called 'cat /proc/<zombie pid>/stack', they would get
> something like this
>
>   [<ffffffff8105b877>] do_exit+0x6f7/0xa80
>   [<ffffffff8105bc79>] do_group_exit+0x39/0xa0
>   [<ffffffff8105bcf0>] __wake_up_parent+0x0/0x30
>   [<ffffffff8152dd09>] system_call_fastpath+0x16/0x1b
>   [<00007fd128f9c4f9>] 0x7fd128f9c4f9
>   [<ffffffffffffffff>] 0xffffffffffffffff
>
> After, one gets nothing. The trace is empty. try_get_task_stack() contains
> atomic_inc_not_zero() (CONFIG_THREAD_INFO_IN_TASK is now default on
> x86_64) and because stack_refcount is 0 for a zombie task, it returns
> NULL. Therefore, all save_stack_trace_*() functions return immediately.
>
> I guess that no one has cared about it so far. There is a problem for
> live patching though. save_stack_trace_tsk_reliable() returns -EINVAL for
> the zombie task and its stack is deemed unreliable. It could block our
> transition for quite a long time.
>
> We can skip those tasks in kernel/livepatch/ with a simple test we have in
> kGraft. Skip the task if (task->state == TASK_DEAD && task->on_cpu == 0).
> But you may want to change it generally, so better to ask first.
>

Sounds like a bug in save_stack_trace_tsk_reliable() to me: if the
task has no stack, then the trace is 100% definitely empty :)