From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50950C2D0E2 for ; Thu, 24 Sep 2020 12:21:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A6025238A1 for ; Thu, 24 Sep 2020 12:21:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Wh7FyLoZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6025238A1 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DCB88900026; Thu, 24 Sep 2020 08:21:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D5598900017; Thu, 24 Sep 2020 08:21:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1BE7900026; Thu, 24 Sep 2020 08:21:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A63CF900017 for ; Thu, 24 Sep 2020 08:21:33 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 647B93635 for ; Thu, 24 Sep 2020 12:21:33 +0000 (UTC) X-FDA: 77297865666.08.sand59_3e17aad2715f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 42D941819E76F for ; Thu, 24 Sep 2020 12:21:33 +0000 (UTC) X-HE-Tag: sand59_3e17aad2715f X-Filterd-Recvd-Size: 6269 Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Thu, 24 Sep 2020 12:21:32 +0000 (UTC) Received: by mail-oi1-f195.google.com with SMTP id v20so3451916oiv.3 for ; Thu, 24 Sep 2020 05:21:32 -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=SMi05EnEOfVdGhWpH6feACxpwD+9PbH32BgxYxZVzjg=; b=Wh7FyLoZl05ePrScyIDLbNcW93hNy+bh0MlhKgZYBOD4Asb3pfcIWi1Qpm7l3BqHeX aq07/YxMJCgggcHSlXRtbFTT+8k7eueARAT3utPtwb4GZW4AENnLmytJkt8R0GevA56h lS8l36/AWFDMX7UM7y0Fu9rrUir7atUDweXTHLhJujpZM6B+ApPh26tQfFHOhtgOin6G +sfgjdXPNGwWX59Da2Kxi4uheKAY3xHsOVuAvvKGwoOiYj6ct+q2HQoYIA+oxQMnVvxJ pzJuS3UvRV+oA4msapQoTTiiQiUb8URNxOrJQ/zHTUdOK5EFIZzhhIVAWDye1y587M2d weXA== 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=SMi05EnEOfVdGhWpH6feACxpwD+9PbH32BgxYxZVzjg=; b=jhJNN49NsqbyjPo+roM4ETRTBhlkLl7kGEzr3eH8zpr33PEsecSg0hOzIx4dRf7AhF 9iFx4bdlPoZrTXo8b2KjWTe4vsdOjmHPRx6u/ikGj9KjJYD4ZCSh9Xvd6OXlrWIkIHWb K3CQewkoUH3CUGLGmyRHWcHGLj4Xnsq5ZazoCAncTwFSL9cEC9oKx7PwKd8Nx0X2BA85 V2XOMGlkMqDVv1eaSdTr+dc/3dz9XU3KxqFNPZKmhZ7IMtWjyDwJrVOZqHh/deKADuX2 0YaP8mfCsxBXHq3mBehDM9hZI+uQXFf6IcmIpZ/DUTnbjFQKgy7ikE6QPhaIQRw7qoAS Nkew== X-Gm-Message-State: AOAM530RIv0yvGLrfpC2x1jiMdF7WxiHIngRVDZ23/ZExuQKxs4Vre3H ymzcMsWXhoShRrKOO2XZTAouXqGTATO6id2nPMG0eA== X-Google-Smtp-Source: ABdhPJyUQSlF1yD+fBHh7KRRnvI1RKY1nulFZ3b80Oct6GlWUeHTquzqD3/u7BnXcXHItepe9G+Pxs7iu3ZAEntp++0= X-Received: by 2002:aca:5158:: with SMTP id f85mr2388516oib.121.1600950091824; Thu, 24 Sep 2020 05:21:31 -0700 (PDT) MIME-Version: 1.0 References: <20200924040513.31051-1-walter-zh.wu@mediatek.com> In-Reply-To: From: Marco Elver Date: Thu, 24 Sep 2020 14:21:20 +0200 Message-ID: Subject: Re: [PATCH v4 3/6] kasan: print timer and workqueue stack To: Alexander Potapenko Cc: Walter Wu , Andrew Morton , Andrey Ryabinin , Dmitry Vyukov , Andrey Konovalov , Matthias Brugger , kasan-dev , Linux Memory Management List , LKML , Linux ARM , wsd_upstream , linux-mediatek@lists.infradead.org Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, 24 Sep 2020 at 14:11, Alexander Potapenko wrote: > > On Thu, Sep 24, 2020 at 1:55 PM Marco Elver wrote: > > > > On Thu, 24 Sep 2020 at 13:47, Alexander Potapenko wrote: > > > > > > On Thu, Sep 24, 2020 at 6:05 AM Walter Wu wrote: > > > > > > > > The aux_stack[2] is reused to record the call_rcu() call stack, > > > > timer init call stack, and enqueuing work call stacks. So that > > > > we need to change the auxiliary stack title for common title, > > > > print them in KASAN report. > > > > > > > > Signed-off-by: Walter Wu > > > > Suggested-by: Marco Elver > > > > Acked-by: Marco Elver > > > > Reviewed-by: Dmitry Vyukov > > > > Reviewed-by: Andrey Konovalov > > > > Cc: Andrey Ryabinin > > > > Cc: Alexander Potapenko > > > > --- > > > > > > > > v2: > > > > - Thanks for Marco suggestion. > > > > - We modify aux stack title name in KASAN report > > > > in order to print call_rcu()/timer/workqueue stack. > > > > > > > > --- > > > > mm/kasan/report.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/mm/kasan/report.c b/mm/kasan/report.c > > > > index 4f49fa6cd1aa..886809d0a8dd 100644 > > > > --- a/mm/kasan/report.c > > > > +++ b/mm/kasan/report.c > > > > @@ -183,12 +183,12 @@ static void describe_object(struct kmem_cache *cache, void *object, > > > > > > > > #ifdef CONFIG_KASAN_GENERIC > > > > if (alloc_info->aux_stack[0]) { > > > > - pr_err("Last call_rcu():\n"); > > > > + pr_err("Last potentially related work creation:\n"); > > > > > > This doesn't have to be a work creation (expect more callers of > > > kasan_record_aux_stack() in the future), so maybe change the wording > > > here to "Last potentially related auxiliary stack"? > > > > I suggested "work creation" as it's the most precise for what it is > > used for now. > > I see, then maybe my suggestion is premature. > > > What other users do you have in mind in future that are not work creation? > > I think saving stacks may help in any case where an object is reused > for a different purpose without reallocation. > SKBs, maybe? I currently don't know, it's hard to say without having a report that we can't debug without it. The litmus test for if it's useful would probably be "do we need this stacktrace to debug a use-after-free/double-free?". If the answer is maybe (and not yes!), I'd err on the side of not going overboard with these, because we only have limited storage anyway. "Work creation" is a clear case of "we loose information to the original caller" and need it to debug. But of course, if there are similar issues elsewhere, we need to identify them and then decide if we need it.