Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1767532ybk; Mon, 11 May 2020 03:56:35 -0700 (PDT) X-Google-Smtp-Source: APiQypL5NxT+iCYgMl7Eb/zV2YnQfk3IM2JoTJOfxYp8ptpIGDYfTmPRrlUD+vaIT5ssAqaG7XS4 X-Received: by 2002:a17:907:2719:: with SMTP id w25mr12985112ejk.107.1589194595412; Mon, 11 May 2020 03:56:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589194595; cv=none; d=google.com; s=arc-20160816; b=QOfOmhrgIn2hHm+xmxzEJLa4gxBSke63wkldZx17Lie34HI4FCN0RslVBmiL7XJw6s pgyrL8zpplGckT+aVNYy2x/mw28JR/IRW2eLjaRRu1rgURrzjlb3xMWVjiFEXwZgDg3M HQiulrSQZR2XrKnLtex5mTdWttWqn1RrCfCrGh3crI6zQ8f2KQho4fECxZ15PpDLiXVt SM//NeoC+zPpfexydAld2jPvD7zK0i8yd7p8sxYjMDWfGDlkg0mDcj2HLE1Cp4cpgz3z EBtt7b00jHZIowd34q2SkmThatX/jEr6XgigL3ymoh7U80vqNcXp+kUKKO9LuUC404g1 UGog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=72CupRCuRPXXCvNwucE/1jDQJJRDxROzY5cHpuICnYs=; b=vYmxXPIzDqQqbRFnJaXA2nQgWueds4E1u5KPERBkVcar+GWmqS5f2Nf3M6KyYiwrFa qbswdYfuQCzL1GkL616ssvfJS0+GEjEYyd81wcJYohTSwXhKRSTpI0nF+PXKDumaMczP J8uh9iR+RC08E6k5z7YEsDKSAEaBVzKkUG+tWiJM8dKJu5hhYKnuXONMzKdj3tKbavZ3 SIU3E1Rsf0CZ/JahlnjnOKocUPxItDR37n91g8dS4gBtH0yO4yabiTBXn69EnB5YShG/ ru/s8FC+wmV5CQ1zv8aIMZh52k+ejvdtN1zA4uZ0dcygCOP39RDdc1dsQxudF7sLtYco JPgw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=ILnkM6H1; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a22si5508452eju.166.2020.05.11.03.56.12; Mon, 11 May 2020 03:56:35 -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=@google.com header.s=20161025 header.b=ILnkM6H1; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729388AbgEKKwd (ORCPT + 99 others); Mon, 11 May 2020 06:52:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1729086AbgEKKwc (ORCPT ); Mon, 11 May 2020 06:52:32 -0400 Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 864DAC061A0C for ; Mon, 11 May 2020 03:52:31 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id x8so7400089qtr.2 for ; Mon, 11 May 2020 03:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=72CupRCuRPXXCvNwucE/1jDQJJRDxROzY5cHpuICnYs=; b=ILnkM6H19JK17KC3M5FAIaz0BrdJVQQCiKVz4hMQKY+zmUQLJmBjxqaofT2C/PU3bR lHITSoyEEq2oW26FnPNPLeLM+tiaSBXyJn5L1+kFGVUjqX7SpOtLm9yp/z6X6p6oEQmH ndb1m0gPuuPgyVNoMkNvQVywYqrDZDn39LAH6xZrCMKOauwpePg1Oz+BIRB6x8nt6d4B lQ1P9Eaw9sPiGAiWu4AhIUnGQrLw2+nsxYKt4JvErU8YbQ0Cb5jgY1s8cq7MP8HPxc76 eUQS+lo9zvS/M7Rt+cjaAuH4xJ64f62hwjRn8smLeYRcRmBvI4hLFUrWOGCgn+0RgD9k 9pNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=72CupRCuRPXXCvNwucE/1jDQJJRDxROzY5cHpuICnYs=; b=kJIPB0cgHR6NnIXMFJboXcRlQvOPAuR3Dde04cEPXeObGMaxol2mcnvd62RvgbZDHB T/OCS29UrfqNyMPg4hHwyZO1d+Imw7hPZFXNL8PgvePREavJLL+Et/haA7RJbRveLr6j NMe30I68GGk6ES9xnRJAWGTr3NopNDNA+rG540IHzyexiY91HirJn0ugnYCC9N2lA9vF bDJ0DIi/TtYK2hmIXX/EUikBq5sBs3ZfKBdi2oj2H4KxCid9bDy0qhw3OiaVvDZ7ZRmM 3p1KBS6vvkWCXpnQ3PGk/ZifpRlriB46FHTu9ZaLmww1i8ziSMJc2L57Wj1VPOWbxf7k 8zXQ== X-Gm-Message-State: AGi0Puah+/0Dgug1F2MD+GN/6XB8NHZvOINW+dEG33g2Jreq1sPs+x0t 8Nl83YpKQvUdBtasCRG2tPSnkbFZ2KmzE/8PA19Pjg== X-Received: by 2002:ac8:370c:: with SMTP id o12mr15522299qtb.380.1589194350352; Mon, 11 May 2020 03:52:30 -0700 (PDT) MIME-Version: 1.0 References: <20200511023231.15437-1-walter-zh.wu@mediatek.com> In-Reply-To: <20200511023231.15437-1-walter-zh.wu@mediatek.com> From: Dmitry Vyukov Date: Mon, 11 May 2020 12:52:19 +0200 Message-ID: Subject: Re: [PATCH v2 3/3] kasan: update documentation for generic kasan To: Walter Wu Cc: Andrey Ryabinin , Alexander Potapenko , Jonathan Corbet , kasan-dev , Linux-MM , LKML , Linux ARM , wsd_upstream , linux-mediatek@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 11, 2020 at 4:32 AM Walter Wu wrote: > > Generic KASAN will support to record first and last call_rcu() call > stack and print them in KASAN report. so we update documentation. > > Signed-off-by: Walter Wu > Cc: Andrey Ryabinin > Cc: Dmitry Vyukov > Cc: Alexander Potapenko > Cc: Jonathan Corbet > --- > Documentation/dev-tools/kasan.rst | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst > index c652d740735d..d4efcfde9fff 100644 > --- a/Documentation/dev-tools/kasan.rst > +++ b/Documentation/dev-tools/kasan.rst > @@ -193,6 +193,12 @@ function calls GCC directly inserts the code to check the shadow memory. > This option significantly enlarges kernel but it gives x1.1-x2 performance > boost over outline instrumented kernel. > > +Currently Currently is excessive here. Everything in the doc is about the current state of the things. > generic KASAN can print call_rcu() s/can print/prints/ > call stack in KASAN report, it KASAN is implied for "report" in this doc. s/KASAN// > +can't increase the cost of memory consumption, It does not increase only as compared to the current state of things. But strictly saying, if we now take the call_rcu stacks away, we can reduce memory consumption. This statement is confusing because stacks consume memory. > but it has one limitations. > +It can't get both call_rcu() call stack and free stack, so that it can't > +print free stack for allocation objects in KASAN report. 1. This sentence produces the impression that KASAN does not print free stack for freed objects. KASAN does still print free stack for freed objects. 2. This sentence is mostly relevant as diff on top of the current situation and thus more suitable for the commit description. We never promise to print free stack for allocated objects. And free stack for allocated objects is not an immediately essential thing either. So for a reader of this doc, this is not a limitation. > This feature is > +only suitable for generic KASAN. We already mentioned "generic" in the first sentence. So this is excessive. This paragraph can be reduced to: "Generic KASAN prints up to 2 call_rcu() call stacks in reports, the first and the last one." The rest belongs to change description and is only interesting as a historic reference. Generally documentation does not accumulate everything that happened since the creation of the world :) > Software tag-based KASAN > ~~~~~~~~~~~~~~~~~~~~~~~~ > > -- > 2.18.0 > > -- > You received this message because you are subscribed to the Google Groups "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20200511023231.15437-1-walter-zh.wu%40mediatek.com.