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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 C2CD6C2D0A3 for ; Wed, 4 Nov 2020 14:56:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 56073223C7 for ; Wed, 4 Nov 2020 14:56:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56073223C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A02196B0071; Wed, 4 Nov 2020 09:56:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B1396B0072; Wed, 4 Nov 2020 09:56:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8789C6B0073; Wed, 4 Nov 2020 09:56:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0141.hostedemail.com [216.40.44.141]) by kanga.kvack.org (Postfix) with ESMTP id 532CF6B0071 for ; Wed, 4 Nov 2020 09:56:12 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id CCD73180AD817 for ; Wed, 4 Nov 2020 14:56:11 +0000 (UTC) X-FDA: 77447036142.26.maid63_0503052272c2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 5A0E71804B661 for ; Wed, 4 Nov 2020 14:56:11 +0000 (UTC) X-HE-Tag: maid63_0503052272c2 X-Filterd-Recvd-Size: 4602 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Wed, 4 Nov 2020 14:56:10 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C1F0E139F; Wed, 4 Nov 2020 06:56:09 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.57.109]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DBD8C3F719; Wed, 4 Nov 2020 06:56:03 -0800 (PST) Date: Wed, 4 Nov 2020 14:56:01 +0000 From: Mark Rutland To: Marco Elver Cc: Andrew Morton , Alexander Potapenko , "H. Peter Anvin" , "Paul E. McKenney" , Andrey Konovalov , Andrey Ryabinin , Andy Lutomirski , Borislav Petkov , Catalin Marinas , Christoph Lameter , Dave Hansen , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Hillf Danton , Ingo Molnar , Jann Horn , Jonathan Cameron , Jonathan Corbet , Joonsoo Kim , =?utf-8?B?SsO2cm4=?= Engel , Kees Cook , Pekka Enberg , Peter Zijlstra , SeongJae Park , Thomas Gleixner , Vlastimil Babka , Will Deacon , the arch/x86 maintainers , "open list:DOCUMENTATION" , LKML , kasan-dev , Linux ARM , Linux Memory Management List Subject: Re: [PATCH v7 3/9] arm64, kfence: enable KFENCE for ARM64 Message-ID: <20201104145601.GB7577@C02TD0UTHF1T.local> References: <20201103175841.3495947-1-elver@google.com> <20201103175841.3495947-4-elver@google.com> <20201104130111.GA7577@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Nov 04, 2020 at 03:23:48PM +0100, Marco Elver wrote: > On Wed, 4 Nov 2020 at 14:06, Mark Rutland wrote: > > On Tue, Nov 03, 2020 at 06:58:35PM +0100, Marco Elver wrote: > > There is one thing that I thing we should improve as a subsequent > > cleanup, but I don't think that should block this as-is. > > > > > +#define KFENCE_SKIP_ARCH_FAULT_HANDLER "el1_sync" > > > > IIUC, the core kfence code is using this to figure out where to trace > > from when there's a fault taken on an access to a protected page. > > Correct. > > > It would be better if the arch code passed the exception's pt_regs into > > the kfence fault handler, and the kfence began the trace began from > > there. That would also allow for dumping the exception registers which > > can help with debugging (e.g. figuring out how the address was derived > > when it's calculated from multiple source registers). That would also be > > a bit more robust to changes in an architectures' exception handling > > code. > > Good idea, thanks. I guess there's no reason to not want to always > skip to instruction_pointer(regs)? I don't think we need the exception handling gunk in the trace, but note that you'd need to use stack_trace_save_regs(regs, ...) directly, rather than using stack_trace_save() and skipping based on instruction_pointer(regs). Otherwise, if the fault was somewhere in an exception handler, and we invoked the same function on the path to the kfence fault handler we might cut the trace at the wrong point. > In which case I can prepare a patch to make this change. If this > should go into a v8, please let me know. But it'd be easier as a > subsequent patch as you say, given it'll be easier to review and these > patches are in -mm now. I think it'd make more sense as a subsequent change, since it's liable to need a cycle or two of review, and I don't think it should block the rest of the series. Thanks, Mark.