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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 3DA51C433E0 for ; Fri, 5 Mar 2021 05:01:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 09CD26500F for ; Fri, 5 Mar 2021 05:01:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229592AbhCEFBZ (ORCPT ); Fri, 5 Mar 2021 00:01:25 -0500 Received: from bilbo.ozlabs.org ([203.11.71.1]:40865 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229494AbhCEFBZ (ORCPT ); Fri, 5 Mar 2021 00:01:25 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4DsFv51fBxz9sWC; Fri, 5 Mar 2021 16:01:21 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ellerman.id.au; s=201909; t=1614920483; bh=HADzFLTJiRHajBtjocr0L74hT5U/LhK0mJtw/ouXjxU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=sEe2yFiC70JfvnTxe0YgAiMh6nPZoEvi0h5USTs843tRe/5UWfhsI5ZfJlPD+sxY8 5UoyDp6tzIGvMLKGfBowCZxj+H5gAiPPDfUoUC5MzRMH2Zxs49/SEwXQf16EpAAU4R ffP5FzEKJXU7IbAiBS+oIXeJPwi4wY4tJefrzbVG/9BQ+//8Vxw3EvpXwoB8PNNS// NxlemWXb2+BNshP5Oi9NpWOViNwMPTW9EEWmXUBh4JGysfFdDoBg7O4auR1uzvBVcQ o+naRGI6YtSJqxX+vvyHHxGVm+N8VzQIGyBfrLdBNapOyGO9Xpd4X5qm8mBaN6MGKc 2pJljh5YD9i4g== From: Michael Ellerman To: Marco Elver , Christophe Leroy Cc: Alexander Potapenko , Benjamin Herrenschmidt , Paul Mackerras , Dmitry Vyukov , LKML , linuxppc-dev@lists.ozlabs.org, kasan-dev Subject: Re: [RFC PATCH v1] powerpc: Enable KFENCE for PPC32 In-Reply-To: References: <08a96c5d-4ae7-03b4-208f-956226dee6bb@csgroup.eu> <7270e1cc-bb6b-99ee-0043-08a027b8d83a@csgroup.eu> Date: Fri, 05 Mar 2021 16:01:15 +1100 Message-ID: <874khqry78.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Marco Elver writes: > On Thu, Mar 04, 2021 at 12:48PM +0100, Christophe Leroy wrote: >> Le 04/03/2021 =C3=A0 12:31, Marco Elver a =C3=A9crit=C2=A0: >> > On Thu, 4 Mar 2021 at 12:23, Christophe Leroy >> > wrote: >> > > Le 03/03/2021 =C3=A0 11:56, Marco Elver a =C3=A9crit : >> > > >=20 >> > > > Somewhat tangentially, I also note that e.g. show_regs(regs) (which >> > > > was printed along the KFENCE report above) didn't include the top >> > > > frame in the "Call Trace", so this assumption is definitely not >> > > > isolated to KFENCE. >> > > >=20 >> > >=20 >> > > Now, I have tested PPC64 (with the patch I sent yesterday to modify = save_stack_trace_regs() >> > > applied), and I get many failures. Any idea ? >> > >=20 >> > > [ 17.653751][ T58] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >> > > [ 17.654379][ T58] BUG: KFENCE: invalid free in .kfence_guarded_= free+0x2e4/0x530 >> > > [ 17.654379][ T58] >> > > [ 17.654831][ T58] Invalid free of 0xc00000003c9c0000 (in kfence= -#77): >> > > [ 17.655358][ T58] .kfence_guarded_free+0x2e4/0x530 >> > > [ 17.655775][ T58] .__slab_free+0x320/0x5a0 >> > > [ 17.656039][ T58] .test_double_free+0xe0/0x198 >> > > [ 17.656308][ T58] .kunit_try_run_case+0x80/0x110 >> > > [ 17.656523][ T58] .kunit_generic_run_threadfn_adapter+0x38/0x50 >> > > [ 17.657161][ T58] .kthread+0x18c/0x1a0 >> > > [ 17.659148][ T58] .ret_from_kernel_thread+0x58/0x70 >> > > [ 17.659869][ T58] > [...] >> >=20 >> > Looks like something is prepending '.' to function names. We expect >> > the function name to appear as-is, e.g. "kfence_guarded_free", >> > "test_double_free", etc. >> >=20 >> > Is there something special on ppc64, where the '.' is some convention? >> >=20 >>=20 >> I think so, see https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64= abi.html#FUNC-DES >>=20 >> Also see commit https://github.com/linuxppc/linux/commit/02424d896 > > Thanks -- could you try the below patch? You'll need to define > ARCH_FUNC_PREFIX accordingly. > > We think, since there are only very few architectures that add a prefix, > requiring to define something like ARCH_FUNC_PREFIX is > the simplest option. Let me know if this works for you. > > There an alternative option, which is to dynamically figure out the > prefix, but if this simpler option is fine with you, we'd prefer it. We have rediscovered this problem in basically every tracing / debugging feature added in the last 20 years :) I think the simplest solution is the one tools/perf/util/symbol.c uses, which is to just skip a leading '.'. Does that work? diff --git a/mm/kfence/report.c b/mm/kfence/report.c index ab83d5a59bb1..67b49dc54b38 100644 --- a/mm/kfence/report.c +++ b/mm/kfence/report.c @@ -67,6 +67,9 @@ static int get_stack_skipnr(const unsigned long stack_ent= ries[], int num_entries for (skipnr =3D 0; skipnr < num_entries; skipnr++) { int len =3D scnprintf(buf, sizeof(buf), "%ps", (void *)stack_entries[ski= pnr]); =20 + if (buf[0] =3D=3D '.') + buf++; + if (str_has_prefix(buf, "kfence_") || str_has_prefix(buf, "__kfence_") || !strncmp(buf, "__slab_free", len)) { /* cheers