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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A0F1C433F5 for ; Tue, 5 Apr 2022 15:37:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 904216B0072; Tue, 5 Apr 2022 11:37:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B35C6B0073; Tue, 5 Apr 2022 11:37:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 753946B0074; Tue, 5 Apr 2022 11:37:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id 6683A6B0072 for ; Tue, 5 Apr 2022 11:37:29 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 06590183CF887 for ; Tue, 5 Apr 2022 15:37:19 +0000 (UTC) X-FDA: 79323229398.23.DA6CD6A Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) by imf09.hostedemail.com (Postfix) with ESMTP id 96537140038 for ; Tue, 5 Apr 2022 15:37:18 +0000 (UTC) Received: by mail-io1-f52.google.com with SMTP id z7so15634772iom.1 for ; Tue, 05 Apr 2022 08:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FtaEgz69DQ819AKh/JUIG3OQ4Q+fmie3I0z6sDwsCCk=; b=dFZM9Jrm29mfxGpXaOsvIRZmFBKbc0AgfvSqpX3EioHJtIEsvWDD/GYPxV+38Ss6kK aSi5BlXbacPVXocOH787r6+R/vBk3hUUaZKk6t1gUvTV1szQ4wil+I9AUrXlJushPlL0 AUBAoWK2P/GkBgUjPd2KTB1I+cGHLXiYQLVf8QiRIZP2IuJwEOOq9A221Zbju6o70rWR Ti+4hXQ5CukVYwGcjeurbmjEzT6ndHMrkpAgA3Zx+OtFytIL3FcUgvGTIxPJLyKTB9SS SGZ37SJm00UTH/TDwyQGs9OOhfNB8HHKRQ33tHsCsm2Iybrwo2AwkIFF07Y/u09MzsvZ 3s4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FtaEgz69DQ819AKh/JUIG3OQ4Q+fmie3I0z6sDwsCCk=; b=PZte9h+bGaTZnmrAiI5iC9yqDQhuDLkCXL8DTDwYDEeKMfqwKQcYMKb1wNCukAY87n k6paVrpeZOsibYuFPuzu3VWXzH4WQxU9rUrBBAYUQlUFs8fdCgNkPdXdGcGq/Nnp+0jZ teeB0aB+68a7qua1IxkTPSyQvTHoEfSWtwnQo+LrCZ4tfKT6cPEPHvUCrZN4ehZm2jtJ 5aDOhzjkjUY3m+U4/CXE5Gq1bGaLjHDIiBAsBKAlKyyJ/RCSg66ttTrELNEh+Ary9quk ZjW8J9yEKZGBkrxHam7NdpeOY2GkalLO6b8wKrVK9DIoq3/hF0jfeRge14O4amS38uBI T8zg== X-Gm-Message-State: AOAM530WTA/ZK781emyWoTJipDE3CJtVl/1KCGKdL5PPp3PX8DzJfvyp kAiqLYynaegzunQfobgtz+cGVtjW19kPtb7zn3U= X-Google-Smtp-Source: ABdhPJzKvUXA4HEqXhmBIGdqKNw+wxPo77cFowOrT7xA9Lsny2Cp5v64TzdBY34Vz1GLSofqMqmZ5tQubR2ncnnPI8M= X-Received: by 2002:a02:b687:0:b0:323:60e7:121a with SMTP id i7-20020a02b687000000b0032360e7121amr2473005jam.22.1649173037888; Tue, 05 Apr 2022 08:37:17 -0700 (PDT) MIME-Version: 1.0 References: <21e3e20ea58e242e3c82c19abbfe65b579e0e4b8.1648049113.git.andreyknvl@google.com> In-Reply-To: From: Andrey Konovalov Date: Tue, 5 Apr 2022 17:37:06 +0200 Message-ID: Subject: Re: [PATCH v2 1/4] stacktrace: add interface based on shadow call stack To: Mark Rutland Cc: andrey.konovalov@linux.dev, Marco Elver , Alexander Potapenko , Catalin Marinas , Will Deacon , Andrew Morton , Dmitry Vyukov , Andrey Ryabinin , kasan-dev , Vincenzo Frascino , Sami Tolvanen , Peter Collingbourne , Evgenii Stepanov , Florian Mayer , Linux Memory Management List , LKML , Andrey Konovalov Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=dFZM9Jrm; spf=pass (imf09.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.166.52 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 96537140038 X-Stat-Signature: bdfuqmzf7rr5yfzax3amxo3szh7q7zke X-HE-Tag: 1649173038-804779 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, Mar 31, 2022 at 11:19 AM Mark Rutland wrote: > > > Collecting stack traces this way is significantly faster: boot time > > of a defconfig build with KASAN enabled gets descreased by ~30%. > > Hmm... just to check, do ou know if that's just because of hte linear copy, or > because we're skipping other work we have to do in the regular stacktrace? No, I haven't looked into this. > > The implementation of the added interface is not meant to use > > stack_trace_consume_fn to avoid making a function call for each > > collected frame to further improve performance. > > ... because we could easily provide an inline-optimized stack copy *without* > having to write a distinct unwinder, and I'd *really* like to avoid having a > bunch of distinct unwinders for arm64, as it really hinders maintenance. We're > working on fixing/improving the arm64 unwinder for things like > RELIABLE_STACKTRACE, and I know that some of that work is non-trivial to make > work with an SCS-based unwind rather than an FP-based unwind, and/or will > undermine the saving anyway. Responded on the cover letter wrt this. > > +int stack_trace_save_shadow(unsigned long *store, unsigned int size, > > + unsigned int skipnr) > > +{ > > + /* > > + * Do not use stack_trace_consume_fn to avoid making a function > > + * call for each collected frame to improve performance. > > + * Skip + 1 frame to skip stack_trace_save_shadow. > > + */ > > + return arch_stack_walk_shadow(store, size, skipnr + 1); > > +} > > +#endif > > If we really need this, can we make it an __always_inline in a header so that > we can avoid the skip? Generally the skipping is problematic due to > inlining/outlining and LTO, and I'd like to avoid adding more of it > unnecessarily. Yes, I think this should work. However, if we keep the implementation in mm/kasan, this integration will not be required. Thanks!