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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6C5EC433FE for ; Tue, 5 Apr 2022 20:15:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1384626AbiDEUFK (ORCPT ); Tue, 5 Apr 2022 16:05:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1457297AbiDEQDE (ORCPT ); Tue, 5 Apr 2022 12:03:04 -0400 Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 742F024F39 for ; Tue, 5 Apr 2022 08:37:18 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id h63so15561021iof.12 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=ZmjCWbDpxNhMGGoIiRiPpx73h8U/15RQMx9aEr8js1UjwXdGzLMAvOztUmeikQRi6z 1FsNo9WqRy+K0q+EF2j5FpS8R94wpcenDqeA9RLxUjpRqGEcvHekPK7ueG+S/boPMLOT grirEILVTMVbhaJe+odL72ct5nRY+fUos8bofZ26gw2BEOH1xE5oA6iwiFU6Z4YROH4c M7wn9W8Da2onVcCPxmgVfbZhcMGRUfeg0wmxG6fkssePOj/HyfZnbwPvwOqP5vm+4YJ8 MC2i9lPq2wiGJWNP4ING8HfLAHNCCjbpHF3gMGFGBuUkG6H6TvAcA6FRuO9kSM7EeNXb 35/g== X-Gm-Message-State: AOAM5331OTjvyDgRbiQRJu1EN6SVjQwRZNZ9PgJtdcPCTvwKIqPbDDxG IlzoGNvFs2e0oPwPI7JNbsaR9onzeP9dX0Qpslk= 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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!