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 7CAD9C433EF for ; Tue, 5 Apr 2022 15:10:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0E146B0071; Tue, 5 Apr 2022 11:10:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 995186B0073; Tue, 5 Apr 2022 11:10:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 837336B0074; Tue, 5 Apr 2022 11:10:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id 739206B0071 for ; Tue, 5 Apr 2022 11:10:16 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 33D0FAB2AF for ; Tue, 5 Apr 2022 15:10:06 +0000 (UTC) X-FDA: 79323160812.19.B9434C8 Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) by imf27.hostedemail.com (Postfix) with ESMTP id A4BA440041 for ; Tue, 5 Apr 2022 15:10:05 +0000 (UTC) Received: by mail-io1-f42.google.com with SMTP id b16so15529097ioz.3 for ; Tue, 05 Apr 2022 08:10:05 -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=odjTcYZDlQIoWSkHe17VwGaSSDqsAiUMG/3xJUCUusY=; b=BIrJnLaJlobJRELofbUGfFGoIys4VbYWUyOHKM6yPYsEcaU68cPexoPGB+FF75wT0l nTLBpmNWQH9/4qlaY0IAqmQ99mQpeHL5s+1WZFh0J7WoAX7+equKRVWQIefnQJGxuh/d 12Uk/NDYJwyFUL3HMR+IHHm9e1DqLhSp1oAk5dW6A9KBz/M3GH2qfDskfkemdyJNjOfZ zklDlMXUPCraZit01xyTMy4mXPhfA6rQp9D9ILWlKYTlfAySHdHSrPXE36e/9K358+yp 2FY/pAh3O3L/Cdc9+eHFv8jK5bnXsezX/to0L2uZ8nOAf+9AnR8YjKHodr+zV3g6F846 Wspw== 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=odjTcYZDlQIoWSkHe17VwGaSSDqsAiUMG/3xJUCUusY=; b=TDxaYTylj5QssPnAZQmK/waVl1h2OJomLJGAmWRnLueHjbWPhU1HAYHQ+hh3D7iGIB 66f9wTdEIEdn6E3MV8/7JRpu5rgjcbS+Eeit96CzZu1/Spu26zx7FedOIOmMiUjuA98v 69UWvGbeJGrMWVhUG0yw+MH6VDq03yLFQvQbkZxiW8lXu1SOPTdES1gBYhauKJhjmfXN /4qPM15X4fVlFnrbr2lg4BVWldejeC3tiufmTcaQibTzakbBtaoNm2rN/f4hxDhQQX5n qkhXah9qEKJuRDPMkXBDWVLPPlIYXhXN8lojGYqrIl0azWKWCOJ5uUoOtk7Vrl3n+ca7 dl2Q== X-Gm-Message-State: AOAM531zPTQWlaFrPMlDUlAi1iaMY7DdMBpS8XR8a+phbIYpfW8YSL8h 9v1hwS64onSDN9waoHqttuLQyra5Nk1Vv8XDRxw= X-Google-Smtp-Source: ABdhPJxAaHeUeJtc2U3f+/5L8fy3AA56uR4U1tXUh2cgSLnkKbaFje6hcmqnAosZq0GKK0ddS4eVRltN814HgJgzkfI= X-Received: by 2002:a02:c89a:0:b0:321:25b2:4b52 with SMTP id m26-20020a02c89a000000b0032125b24b52mr2152926jao.218.1649171404854; Tue, 05 Apr 2022 08:10:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andrey Konovalov Date: Tue, 5 Apr 2022 17:09:54 +0200 Message-ID: Subject: Re: [PATCH v2 0/4] kasan, arm64, scs, stacktrace: collect stack traces from 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" X-Stat-Signature: gm9mtswytb78tzxju6k4cnacsbftor9b Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BIrJnLaJ; spf=pass (imf27.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.166.42 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: A4BA440041 X-HE-Tag: 1649171405-848739 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:54 AM Mark Rutland wrote: > > That is an impressive number. TBH, I'm shocked that this has *that* much of an > improvement, and I suspect this means we're doing something unnecssarily > expensive in the regular unwinder. > > I've given some specific comments on patches, but a a high-level, I don't want > to add yet another unwind mechanism. For maintenance and correctness reasons, > we've spent the last few years consolidating various unwinders, which this > unfortunately goes against. > > I see that there are number of cases this unwinder will fall afoul of (e.g. > kretprobes and ftrace graph trampolines), and making those work correctly will > require changes elsewhere (e.g. as we rely upon a snapshot of the FP to > disambiguate cases today). Do I understand correctly that kretprobes and ftrace modify frames saved on SCS? So, if either is enabled, SCS frames might contain their addresses instead of actual PCs? If so, this is good enough for our use case. Having kretprobes or ftrace enabled is an unusual setting and there's no requirement to support it. The goal is to have stack trace collection working in most cases during a normal usage of an Android device. Being not feature-complete and not covering all possible peculiar cases is fine. > I'm also very much not keen on having to stash things in the entry assembly for > this distinct unwinder. I'll drop these changes, I'll respond on that patch. > Going forward, I'm also planning on making changes to the way we unwind across > exception boundaries (e.g. to report the LR and FP), and as that depends on > finding the pt_regs based on the FP, that's not going to work with SCS. > > So at a high level, I don't want to add an SCS based unwinder. > > However, I'm very much open to how we could improve the standard unwinder to be > faster, which would be more generally beneficial. I can see that there are some > things we could reasonably do with simple refactoring. The intention of adding an SCS-based unwinder it to use in production together with MTE-based KASAN. Thus, it needs to be as fast as possible. I doubt even a very optimized FP-based unwinder will compare with a simple loop over SCS frames. It seems a pity to let the kernel maintain the current call trace via SCS and then not to use it to collect stack traces. Would it be acceptable if we keep the SCS unwinder code in mm/kasan and not integrate with the common stacktrace machanisms? Thanks!