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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 00BF7C433E0 for ; Thu, 4 Mar 2021 11:50:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CDBE564F2B for ; Thu, 4 Mar 2021 11:50:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238933AbhCDLuK (ORCPT ); Thu, 4 Mar 2021 06:50:10 -0500 Received: from pegase1.c-s.fr ([93.17.236.30]:12714 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233491AbhCDLtn (ORCPT ); Thu, 4 Mar 2021 06:49:43 -0500 Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 4Drpzp3xTYz9v1sK; Thu, 4 Mar 2021 12:48:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id h-mitI98mN7r; Thu, 4 Mar 2021 12:48:54 +0100 (CET) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 4Drpzp2DxPz9v1sG; Thu, 4 Mar 2021 12:48:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 2270C8B7FF; Thu, 4 Mar 2021 12:48:56 +0100 (CET) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id VRrx4alowTpf; Thu, 4 Mar 2021 12:48:56 +0100 (CET) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 665B48B773; Thu, 4 Mar 2021 12:48:55 +0100 (CET) Subject: Re: [RFC PATCH v1] powerpc: Enable KFENCE for PPC32 To: Marco Elver Cc: Alexander Potapenko , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Dmitry Vyukov , LKML , linuxppc-dev@lists.ozlabs.org, kasan-dev References: <51c397a23631d8bb2e2a6515c63440d88bf74afd.1614674144.git.christophe.leroy@csgroup.eu> <08a96c5d-4ae7-03b4-208f-956226dee6bb@csgroup.eu> From: Christophe Leroy Message-ID: <7270e1cc-bb6b-99ee-0043-08a027b8d83a@csgroup.eu> Date: Thu, 4 Mar 2021 12:48:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 04/03/2021 à 12:31, Marco Elver a écrit : > On Thu, 4 Mar 2021 at 12:23, Christophe Leroy > wrote: >> Le 03/03/2021 à 11:56, Marco Elver a écrit : >>> >>> 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. >>> >> >> 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 ? >> >> [ 17.653751][ T58] ================================================================== >> [ 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] >> [ 17.663954][ T58] kfence-#77 [0xc00000003c9c0000-0xc00000003c9c001f, size=32, cache=kmalloc-32] >> allocated by task 58: >> [ 17.666113][ T58] .__kfence_alloc+0x1bc/0x510 >> [ 17.667069][ T58] .__kmalloc+0x280/0x4f0 >> [ 17.667452][ T58] .test_alloc+0x19c/0x430 >> [ 17.667732][ T58] .test_double_free+0x88/0x198 >> [ 17.667971][ T58] .kunit_try_run_case+0x80/0x110 >> [ 17.668283][ T58] .kunit_generic_run_threadfn_adapter+0x38/0x50 >> [ 17.668553][ T58] .kthread+0x18c/0x1a0 >> [ 17.669315][ T58] .ret_from_kernel_thread+0x58/0x70 >> [ 17.669711][ T58] >> [ 17.669711][ T58] freed by task 58: >> [ 17.670116][ T58] .kfence_guarded_free+0x3d0/0x530 >> [ 17.670421][ T58] .__slab_free+0x320/0x5a0 >> [ 17.670603][ T58] .test_double_free+0xb4/0x198 >> [ 17.670827][ T58] .kunit_try_run_case+0x80/0x110 >> [ 17.671073][ T58] .kunit_generic_run_threadfn_adapter+0x38/0x50 >> [ 17.671410][ T58] .kthread+0x18c/0x1a0 >> [ 17.671618][ T58] .ret_from_kernel_thread+0x58/0x70 >> [ 17.671972][ T58] >> [ 17.672638][ T58] CPU: 0 PID: 58 Comm: kunit_try_catch Tainted: G B >> 5.12.0-rc1-01540-g0783285cc1b8-dirty #4685 >> [ 17.673768][ T58] ================================================================== >> [ 17.677031][ T58] # test_double_free: EXPECTATION FAILED at mm/kfence/kfence_test.c:380 >> [ 17.677031][ T58] Expected report_matches(&expect) to be true, but is false >> [ 17.684397][ T1] not ok 7 - test_double_free >> [ 17.686463][ T59] # test_double_free-memcache: setup_test_cache: size=32, ctor=0x0 >> [ 17.688403][ T59] # test_double_free-memcache: test_alloc: size=32, gfp=cc0, policy=any, >> cache=1 > > 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. > > Is there something special on ppc64, where the '.' is some convention? > I think so, see https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES Also see commit https://github.com/linuxppc/linux/commit/02424d896 Christophe 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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 44E01C433DB for ; Thu, 4 Mar 2021 11:49:23 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 58A4E64EED for ; Thu, 4 Mar 2021 11:49:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 58A4E64EED Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=csgroup.eu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Drq0J5W6dz3d8c for ; Thu, 4 Mar 2021 22:49:20 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=csgroup.eu (client-ip=93.17.236.30; helo=pegase1.c-s.fr; envelope-from=christophe.leroy@csgroup.eu; receiver=) Received: from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Drpzy0bN0z30hv for ; Thu, 4 Mar 2021 22:48:59 +1100 (AEDT) Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 4Drpzp3xTYz9v1sK; Thu, 4 Mar 2021 12:48:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id h-mitI98mN7r; Thu, 4 Mar 2021 12:48:54 +0100 (CET) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 4Drpzp2DxPz9v1sG; Thu, 4 Mar 2021 12:48:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 2270C8B7FF; Thu, 4 Mar 2021 12:48:56 +0100 (CET) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id VRrx4alowTpf; Thu, 4 Mar 2021 12:48:56 +0100 (CET) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 665B48B773; Thu, 4 Mar 2021 12:48:55 +0100 (CET) Subject: Re: [RFC PATCH v1] powerpc: Enable KFENCE for PPC32 To: Marco Elver References: <51c397a23631d8bb2e2a6515c63440d88bf74afd.1614674144.git.christophe.leroy@csgroup.eu> <08a96c5d-4ae7-03b4-208f-956226dee6bb@csgroup.eu> From: Christophe Leroy Message-ID: <7270e1cc-bb6b-99ee-0043-08a027b8d83a@csgroup.eu> Date: Thu, 4 Mar 2021 12:48:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: LKML , kasan-dev , Alexander Potapenko , Paul Mackerras , linuxppc-dev@lists.ozlabs.org, Dmitry Vyukov Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Le 04/03/2021 à 12:31, Marco Elver a écrit : > On Thu, 4 Mar 2021 at 12:23, Christophe Leroy > wrote: >> Le 03/03/2021 à 11:56, Marco Elver a écrit : >>> >>> 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. >>> >> >> 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 ? >> >> [ 17.653751][ T58] ================================================================== >> [ 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] >> [ 17.663954][ T58] kfence-#77 [0xc00000003c9c0000-0xc00000003c9c001f, size=32, cache=kmalloc-32] >> allocated by task 58: >> [ 17.666113][ T58] .__kfence_alloc+0x1bc/0x510 >> [ 17.667069][ T58] .__kmalloc+0x280/0x4f0 >> [ 17.667452][ T58] .test_alloc+0x19c/0x430 >> [ 17.667732][ T58] .test_double_free+0x88/0x198 >> [ 17.667971][ T58] .kunit_try_run_case+0x80/0x110 >> [ 17.668283][ T58] .kunit_generic_run_threadfn_adapter+0x38/0x50 >> [ 17.668553][ T58] .kthread+0x18c/0x1a0 >> [ 17.669315][ T58] .ret_from_kernel_thread+0x58/0x70 >> [ 17.669711][ T58] >> [ 17.669711][ T58] freed by task 58: >> [ 17.670116][ T58] .kfence_guarded_free+0x3d0/0x530 >> [ 17.670421][ T58] .__slab_free+0x320/0x5a0 >> [ 17.670603][ T58] .test_double_free+0xb4/0x198 >> [ 17.670827][ T58] .kunit_try_run_case+0x80/0x110 >> [ 17.671073][ T58] .kunit_generic_run_threadfn_adapter+0x38/0x50 >> [ 17.671410][ T58] .kthread+0x18c/0x1a0 >> [ 17.671618][ T58] .ret_from_kernel_thread+0x58/0x70 >> [ 17.671972][ T58] >> [ 17.672638][ T58] CPU: 0 PID: 58 Comm: kunit_try_catch Tainted: G B >> 5.12.0-rc1-01540-g0783285cc1b8-dirty #4685 >> [ 17.673768][ T58] ================================================================== >> [ 17.677031][ T58] # test_double_free: EXPECTATION FAILED at mm/kfence/kfence_test.c:380 >> [ 17.677031][ T58] Expected report_matches(&expect) to be true, but is false >> [ 17.684397][ T1] not ok 7 - test_double_free >> [ 17.686463][ T59] # test_double_free-memcache: setup_test_cache: size=32, ctor=0x0 >> [ 17.688403][ T59] # test_double_free-memcache: test_alloc: size=32, gfp=cc0, policy=any, >> cache=1 > > 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. > > Is there something special on ppc64, where the '.' is some convention? > I think so, see https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES Also see commit https://github.com/linuxppc/linux/commit/02424d896 Christophe