All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Marco Elver <elver@google.com>
Cc: Alexander Potapenko <glider@google.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Dmitry Vyukov <dvyukov@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linuxppc-dev@lists.ozlabs.org,
	kasan-dev <kasan-dev@googlegroups.com>
Subject: Re: [RFC PATCH v1] powerpc: Enable KFENCE for PPC32
Date: Thu, 4 Mar 2021 12:48:56 +0100	[thread overview]
Message-ID: <7270e1cc-bb6b-99ee-0043-08a027b8d83a@csgroup.eu> (raw)
In-Reply-To: <CANpmjNMn_CUrgeSqBgiKx4+J8a+XcxkaLPWoDMUvUEXk8+-jxg@mail.gmail.com>



Le 04/03/2021 à 12:31, Marco Elver a écrit :
> On Thu, 4 Mar 2021 at 12:23, Christophe Leroy
> <christophe.leroy@csgroup.eu> 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

WARNING: multiple messages have this Message-ID (diff)
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Marco Elver <elver@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>,
	Alexander Potapenko <glider@google.com>,
	Paul Mackerras <paulus@samba.org>,
	linuxppc-dev@lists.ozlabs.org, Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [RFC PATCH v1] powerpc: Enable KFENCE for PPC32
Date: Thu, 4 Mar 2021 12:48:56 +0100	[thread overview]
Message-ID: <7270e1cc-bb6b-99ee-0043-08a027b8d83a@csgroup.eu> (raw)
In-Reply-To: <CANpmjNMn_CUrgeSqBgiKx4+J8a+XcxkaLPWoDMUvUEXk8+-jxg@mail.gmail.com>



Le 04/03/2021 à 12:31, Marco Elver a écrit :
> On Thu, 4 Mar 2021 at 12:23, Christophe Leroy
> <christophe.leroy@csgroup.eu> 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

  reply	other threads:[~2021-03-04 11:50 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02  8:37 [RFC PATCH v1] powerpc: Enable KFENCE for PPC32 Christophe Leroy
2021-03-02  8:37 ` Christophe Leroy
2021-03-02  8:58 ` Marco Elver
2021-03-02  8:58   ` Marco Elver
2021-03-02  9:05   ` Christophe Leroy
2021-03-02  9:05     ` Christophe Leroy
2021-03-02  9:21     ` Alexander Potapenko
2021-03-02  9:21       ` Alexander Potapenko
2021-03-02  9:27       ` Christophe Leroy
2021-03-02  9:27         ` Christophe Leroy
2021-03-02  9:53         ` Marco Elver
2021-03-02  9:53           ` Marco Elver
2021-03-02 11:21           ` Christophe Leroy
2021-03-02 11:21             ` Christophe Leroy
2021-03-02 11:39             ` Marco Elver
2021-03-02 11:39               ` Marco Elver
2021-03-03 10:38               ` Christophe Leroy
2021-03-03 10:38                 ` Christophe Leroy
2021-03-03 10:56                 ` Marco Elver
2021-03-03 10:56                   ` Marco Elver
2021-03-04 11:23                   ` Christophe Leroy
2021-03-04 11:23                     ` Christophe Leroy
2021-03-04 11:31                     ` Marco Elver
2021-03-04 11:31                       ` Marco Elver
2021-03-04 11:48                       ` Christophe Leroy [this message]
2021-03-04 11:48                         ` Christophe Leroy
2021-03-04 12:00                         ` Christophe Leroy
2021-03-04 12:00                           ` Christophe Leroy
2021-03-04 12:02                           ` Marco Elver
2021-03-04 12:02                             ` Marco Elver
2021-03-04 12:48                         ` Marco Elver
2021-03-04 12:48                           ` Marco Elver
2021-03-04 14:08                           ` Christophe Leroy
2021-03-04 14:08                             ` Christophe Leroy
2021-03-04 14:19                             ` Marco Elver
2021-03-04 14:19                               ` Marco Elver
2021-03-05  5:01                           ` Michael Ellerman
2021-03-05  5:01                             ` Michael Ellerman
2021-03-05  7:50                             ` Marco Elver
2021-03-05  7:50                               ` Marco Elver
2021-03-05  8:23                               ` Christophe Leroy
2021-03-05  8:23                                 ` Christophe Leroy
2021-03-05  9:14                                 ` Marco Elver
2021-03-05  9:14                                   ` Marco Elver
2021-03-05 11:49                                   ` Michael Ellerman
2021-03-05 11:49                                     ` Michael Ellerman
2021-03-05 13:46                                     ` Marco Elver
2021-03-05 13:46                                       ` Marco Elver
2021-03-02 11:40             ` Michael Ellerman
2021-03-02 11:40               ` Michael Ellerman
2021-03-02 18:48               ` Segher Boessenkool
2021-03-02 18:48                 ` Segher Boessenkool
2021-03-03 10:28               ` Christophe Leroy
2021-03-03 10:28                 ` Christophe Leroy
2021-03-03 10:31           ` Christophe Leroy
2021-03-03 10:31             ` Christophe Leroy
2021-03-03 10:39             ` Marco Elver
2021-03-03 10:39               ` Marco Elver
2021-03-03 10:56               ` Christophe Leroy
2021-03-03 10:56                 ` Christophe Leroy
     [not found]             ` <CANpmjNMKEObjf=WyfDQB5vPmR5RuyUMBJyfr6P2ykCd67wyMbA__49537.1361424745$1614767987$gmane$org@mail.gmail.com>
2021-03-03 10:46               ` Andreas Schwab
2021-03-03 10:46                 ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7270e1cc-bb6b-99ee-0043-08a027b8d83a@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=benh@kernel.crashing.org \
    --cc=dvyukov@google.com \
    --cc=elver@google.com \
    --cc=glider@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.