Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4734272imm; Mon, 20 Aug 2018 23:29:39 -0700 (PDT) X-Google-Smtp-Source: AA+uWPy6bRdFFG9/pYnZUSNLDgiUi0LkqOlnvLq25Jo9ZtQoXFQBNv9sFxZPkd0kOP+mGeIXIWtQ X-Received: by 2002:a63:2214:: with SMTP id i20-v6mr11912795pgi.212.1534832979517; Mon, 20 Aug 2018 23:29:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534832979; cv=none; d=google.com; s=arc-20160816; b=QElBgh55nuTxGH4G4KoX9YShaKsrOdrhJH+Wk+tZTBsA4eKgStGMHyNGAHNvNn3DV1 3MJInGWeS8UZnOzorLk8/L6aSsyUNFcfkyl5a37Ls/+XqXMa5MF3BxqefsE1AB0qL2U0 8t5iNFde5GWaVGq0EnodI98DOMBs1yNSKUqkdxbxs6bYaVSjohVkTrOvYWI70yI02/Dv OYJycRLGH+N/MkggAlXVIt7b3w8juBo7GbH4WfPc7ejQpjuHkZLS2L2n2TKhQywmrrZF pGcFPNcOQ8xOu+3LdGWkebHTH+qYcx6xX+H6hC3DtFcml79RB54WTMyCrhBlN/nh8xkO 5B3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:arc-authentication-results; bh=Ukbnh8chnS0uFeL87MwjS+I9wa5L/+OLbZ7J01gYCFA=; b=Z0S1RmWgIYFYxAqOXLvrnMRLLhZzw3712iGL/ZPqzvk6n3xhcOooyFg4DUAoiqWdWg blayMLJUUkUB8BCXB5LO+Dwq+X48oJvjSZBFupIPwdkaHo4JodhQw4OMMX4iQ6351sPB D28kaxaMUwfycJ9MDNUeMaj4l2rW9BiqZtuBIc41BoszpRRJ/zbqSigdYbEMMRFk+ep7 nZ34rB+jC5xAQV2iAwtWYBBemR5eflmPMDDK12Ha0tlpXXPss9LxFmcG4gu97iY+57FC 9HY+FU2VRUxMJ0nzBE/CIrKqVMuUSeMRhgVxwOH08rEqJ1t976iqQ80k/XKq5U6L9bwj EGjQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t8-v6si11740929plo.319.2018.08.20.23.29.24; Mon, 20 Aug 2018 23:29:39 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728700AbeHUJqe (ORCPT + 99 others); Tue, 21 Aug 2018 05:46:34 -0400 Received: from ozlabs.org ([203.11.71.1]:58423 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727742AbeHUJqd (ORCPT ); Tue, 21 Aug 2018 05:46:33 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 41vghc6m3qz9sBs; Tue, 21 Aug 2018 16:27:44 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras , muriloo@linux.ibm.com Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 1/2] powerpc/process: fix nested output in show_user_instructions() In-Reply-To: <718cc9c9bd1d4bb2b4c2596f1a7ee00334e77055.1534192631.git.christophe.leroy@c-s.fr> References: <718cc9c9bd1d4bb2b4c2596f1a7ee00334e77055.1534192631.git.christophe.leroy@c-s.fr> Date: Tue, 21 Aug 2018 16:27:44 +1000 Message-ID: <877ekkmdy7.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christophe Leroy writes: > When two processes crash at the same time, we sometimes encounter > nesting in the middle of a line: I think "interleaved" is the right word, rather than "nesting". They're actually (potentially) completely unrelated segfaults, that just happen to occur at the same time. And in fact any output that happens simultaneously will mess things up, it doesn't have to be another segfault. > [ 4.365317] init[1]: segfault (11) at 0 nip 0 lr 0 code 1 > [ 4.370452] init[1]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX > [ 4.372042] init[74]: segfault (11) at 10a74 nip 1000c198 lr 100078c8 code 1 in sh[10000000+14000] > [ 4.386829] XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX > [ 4.391542] init[1]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX > [ 4.400863] init[74]: code: 90010024 bf61000c 91490a7c 3fa01002 3be00000 7d3e4b78 3bbd0c20 3b600000 > [ 4.409867] init[74]: code: 3b9d0040 7c7fe02e 2f830000 419e0028 <89230000> 2f890000 41be001c 4b7f6e79 > > This patch fixes it by preparing complete lines in a buffer and > printing it at once. > > Fixes: 88b0fe1757359 ("powerpc: Add show_user_instructions()") > Cc: Murilo Opsfelder Araujo > Signed-off-by: Christophe Leroy > --- > arch/powerpc/kernel/process.c | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c > index 913c5725cdb2..c722ce4ca1c0 100644 > --- a/arch/powerpc/kernel/process.c > +++ b/arch/powerpc/kernel/process.c > @@ -1303,32 +1303,33 @@ void show_user_instructions(struct pt_regs *regs) > { > unsigned long pc; > int i; > + char buf[96]; /* enough for 8 times 9 + 2 chars */ > + int l = 0; I'm sure your math is right, but still an on-stack buffer with sprintf() is a bit scary. Can you try using seq_buf instead? It is safe against overflow. eg, something like: struct seq_buf s; char buf[96]; seq_buf_init(&s, buf, sizeof(buf)); ... seq_buf_printf(&s, ...); cheers