Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2176280yba; Fri, 17 May 2019 11:52:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqzZAUzuRu4L3VEbcLs6dGMk+cuq9YQKTNiKZHqx4WQyUOo3tpMeWtZ4vyq+BwIokSuiiX5B X-Received: by 2002:a17:902:f20b:: with SMTP id gn11mr58592085plb.126.1558119178890; Fri, 17 May 2019 11:52:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558119178; cv=none; d=google.com; s=arc-20160816; b=m7qL/qO3jBOfk3+Q2PeZbgSWcWnUXByWFz9ygY9sZ4odjikCi6/ged5DP86mBBvipG sukbOSImwJ93B5rasf+Q7G8T8ZQUWUJabgf3eMVGHnzPI9WWg34Gpm5yhwm/U7izJhMs qXOlrgnJygvOixNnZZpFhafbqxcR8vs1bmQNI7+yiR/ODyaEcmJwTdDE+A8C0JKRiwj2 bWg0UA0oC0dqoRl/hGyxnSL5bGiZZAvz/9dQXAPiJfIS+WdGwURqPrHi7kqbA8hfPNwi vRy6r3sbYVd33x2owxU3q7cO8Xn+qOkT47ZfaJuOMo3CStzehHUF6tis1xKxhEzyDB5S z6pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=+e05eNO1EJq44ZRnaYgkjzmQwxR7x070XZQAN5nNKkY=; b=FS+omwJBVT8MtMiEx7FEBAXaO3//sQB36CotMV3Qy++SfnZYw0msmBu7wsJrSlaP7S UyDFXh29PfPvL84FCYur+POayJ6e3LRl9H+hBriE3oUH3rMO0rY7/yi6z6Q1DpmbCdJe K3tdUQ626bXxT1UY+sKHOEnz2hW/wNs6R4DjWzVAHz9wFo2ih8lHWPnIEYkX5gnCnGai Ig8E2wOw1evc3pRax0LpPRHZqn7ctNhHZ3Ebb0VblJgThu/t27u0Dlpq8Je7hvee8Gr4 aK22oDFd7gcUJbj+UVn0PHwNIi+x83TXoHLWHI0xUbkWViYEK4tGEufjP+p9YuF98HVW wbFg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b13si5084461pgg.389.2019.05.17.11.52.43; Fri, 17 May 2019 11:52:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727474AbfEQSvk (ORCPT + 99 others); Fri, 17 May 2019 14:51:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43834 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726732AbfEQSvk (ORCPT ); Fri, 17 May 2019 14:51:40 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 26FB8C09AD16; Fri, 17 May 2019 18:51:40 +0000 (UTC) Received: from jlaw-desktop.bos.redhat.com (dhcp-17-208.bos.redhat.com [10.18.17.208]) by smtp.corp.redhat.com (Postfix) with ESMTP id 28DBC413C; Fri, 17 May 2019 18:51:35 +0000 (UTC) From: Joe Lawrence To: live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Cc: jikos@kernel.org, joe.lawrence@redhat.com, jpoimboe@redhat.com, pmladek@suse.com, tglx@linutronix.de Subject: [PATCH] stacktrace: fix CONFIG_ARCH_STACKWALK stack_trace_save_tsk_reliable return Date: Fri, 17 May 2019 14:51:17 -0400 Message-Id: <20190517185117.24642-1-joe.lawrence@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 17 May 2019 18:51:40 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Miroslav reported that the livepatch self-tests were failing, specifically a case in which the consistency model ensures that we do not patch a current executing function, "TEST: busy target module". Recent renovations to stack_trace_save_tsk_reliable() left it returning only an -ERRNO success indication in some configuration combinations: klp_check_stack() ret = stack_trace_save_tsk_reliable() #ifdef CONFIG_ARCH_STACKWALK && CONFIG_HAVE_RELIABLE_STACKTRACE stack_trace_save_tsk_reliable() ret = arch_stack_walk_reliable() return 0 return -EINVAL ... return ret; ... if (ret < 0) /* stack_trace_save_tsk_reliable error */ nr_entries = ret; << 0 Previously (and currently for !CONFIG_ARCH_STACKWALK && CONFIG_HAVE_RELIABLE_STACKTRACE) stack_trace_save_tsk_reliable() returned the number of entries that it consumed in the passed storage array. In the case of the above config and trace, be sure to return the stacktrace_cookie.len on stack_trace_save_tsk_reliable() success. Fixes: 25e39e32b0a3f ("livepatch: Simplify stack trace retrieval") Reported-by: Miroslav Benes Signed-off-by: Joe Lawrence --- kernel/stacktrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/stacktrace.c b/kernel/stacktrace.c index 27bafc1e271e..90d3e0bf0302 100644 --- a/kernel/stacktrace.c +++ b/kernel/stacktrace.c @@ -206,7 +206,7 @@ int stack_trace_save_tsk_reliable(struct task_struct *tsk, unsigned long *store, ret = arch_stack_walk_reliable(consume_entry, &c, tsk); put_task_stack(tsk); - return ret; + return ret ? ret : c.len; } #endif -- 2.20.1