Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp134011pxx; Wed, 28 Oct 2020 00:07:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx3rERQ1ERgtPT6HlNdYakKA5/vv4Gvhd98c0mpYBD2ChD5umU8dGUCeLcMsQTE2Ryf+40l X-Received: by 2002:a17:906:388d:: with SMTP id q13mr6029216ejd.92.1603868868354; Wed, 28 Oct 2020 00:07:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603868868; cv=none; d=google.com; s=arc-20160816; b=dbT540oQmjTECY4t+vWrTVlpW/olTSojK5Jj9uT2spvIFcaUYfU3bk01C+CpqAzygV Ph5Fj2uyK7VGqjTZ/3ivYYd2fCzpk0bDcEDi2kWUqtG3TgmPoNCS1McGOHETjcel2k4K 0tcFa7m2+2PxYtbzsAjZnFCAhUFXz+3tVDVgeGnH2Q48DNa6WBNrz16Ao1n7U0M9Sjgd qnpQE8EoRSCF/f2h907yCeOHzXP4cd/ivata8uEq+U8U8Tb5+8HBfWs3RR11GUIO92zo 5oLav3uPKZCG69rcGqyw/pNlpXEMNwvpLi6+zrSnZhpQg1fx6u6M2wug7VeXqm5M7OAj ofpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=GnxDeGmTMUPaCY3lsvPzLW9g+uQZ2HFO8L2cAvETF+M=; b=jQHbSimt3mcy33e6xb8Z2Pi+XIgCxp+4eCwtnDTRglT/G8u4UdFDlb1xfLrThvGBJt V7gWWysVX8jFjIUUw342JuXSev9ngYoSjCoynMapxHuWqMi7R/t5w5Ihe4OXM5CnG5yX 7SYR3X1XxUFpnQaHL6Rmcb36bHjX5lPUdu6nCHA0Xjdj3eBpLJGsVBrxKIex8NiwbDfQ yLeg/kUMyobj091b1Uo9BQuhDbWCOEREq0CXbD/3zOHnJNPSZg8LvaEhu5zJ1hKWxQ6k PUbM67G10R2MiPbsdwCy1kvvrWCX3e9XqDDSmKf3cCJHvB4fFuPs8iXwQD34x7eJ2cqq yOAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=Rn4TkiR6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t16si2635764ejb.494.2020.10.28.00.07.26; Wed, 28 Oct 2020 00:07:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=Rn4TkiR6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2899071AbgJ0LQg (ORCPT + 99 others); Tue, 27 Oct 2020 07:16:36 -0400 Received: from mx2.suse.de ([195.135.220.15]:33158 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2899062AbgJ0LQf (ORCPT ); Tue, 27 Oct 2020 07:16:35 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1603797393; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=GnxDeGmTMUPaCY3lsvPzLW9g+uQZ2HFO8L2cAvETF+M=; b=Rn4TkiR6JDIP8AdqOgSa9mZ1yGMho72joE9GOMkfgcnsrjlqb9HUnkQBlgNyANXAKrrd6f 2haG6Pv0L6EC3DDnbg9CNZo7MiDiIDqM7KSHD1+eih8HczaYo67lds/KrkXvHZT7U5WUN6 SAq1gtwn2SkF4TmjL0q4qXKS6IzUgks= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 3739FAF06; Tue, 27 Oct 2020 11:16:33 +0000 (UTC) Date: Tue, 27 Oct 2020 12:16:32 +0100 From: Petr Mladek To: Mark Rutland Cc: linux-kernel@vger.kernel.org, Jiri Kosina , Joe Lawrence , Jonathan Corbet , Josh Poimboeuf , Mark Brown , Miroslav Benes , linux-doc@vger.kernel.org, live-patching@vger.kernel.org Subject: Re: [PATCH] Documentation: livepatch: document reliable stacktrace Message-ID: <20201027111559.GC31882@alley> References: <20201023153527.36346-1-mark.rutland@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201023153527.36346-1-mark.rutland@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 2020-10-23 16:35:27, Mark Rutland wrote: > Add documentation for reliable stacktrace. This is intended to describe > the semantics and to be an aid for implementing architecture support for > HAVE_RELIABLE_STACKTRACE. First, thanks a lot for putting this document together. I am not expert on stack unwinders and am not sure if some details should get corrected and added. I believe that it can be done by others more effectively. Anyway, the document is well readable and provides a lot of useful information. I suggest only small change in the style, see below. > diff --git a/Documentation/livepatch/reliable-stacktrace.rst b/Documentation/livepatch/reliable-stacktrace.rst > new file mode 100644 > index 0000000000000..d296c93f6f0e0 > --- /dev/null > +++ b/Documentation/livepatch/reliable-stacktrace.rst > +2. Requirements > +=============== > + > +Architectures must implement one of the reliable stacktrace functions. > +Architectures using CONFIG_ARCH_STACKWALK should implement > +'arch_stack_walk_reliable', and other architectures should implement > +'save_stack_trace_tsk_reliable'. > + > +Principally, the reliable stacktrace function must ensure that either: > + > +* The trace includes all functions that the task may be returned to, and the > + return code is zero to indicate that the trace is reliable. > + > +* The return code is non-zero to indicate that the trace is not reliable. > + > +.. note:: > + In some cases it is legitimate to omit specific functions from the trace, > + but all other functions must be reported. These cases are described in > + futher detail below. > + > +Secondly, the reliable stacktrace function should be robust to cases where the > +stack or other unwind state is corrupt or otherwise unreliable. The function > +should attempt to detect such cases and return a non-zero error code, and > +should not get stuck in an infinite loop or access memory in an unsafe way. > +Specific cases are described in further detail below. Please, use imperative style when something is required for the reliability. For example, it means replacing all "should" with "must" in the above paragraph. I perfectly understand why you used "should". I use it heavily as well. But we really must motivate people to handle all corner cases here. ;-) Best Regards, Petr