Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755970AbdLOMzA (ORCPT ); Fri, 15 Dec 2017 07:55:00 -0500 Received: from mx2.suse.de ([195.135.220.15]:57294 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755553AbdLOMy6 (ORCPT ); Fri, 15 Dec 2017 07:54:58 -0500 Date: Fri, 15 Dec 2017 13:54:56 +0100 (CET) From: Miroslav Benes To: luto@kernel.org, jpoimboe@redhat.com cc: x86@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org Subject: stack traces and zombie tasks Message-ID: User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1374 Lines: 33 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//stack', they would get something like this [] do_exit+0x6f7/0xa80 [] do_group_exit+0x39/0xa0 [] __wake_up_parent+0x0/0x30 [] system_call_fastpath+0x16/0x1b [<00007fd128f9c4f9>] 0x7fd128f9c4f9 [] 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. Regards, Miroslav