linux-kernel - RE: [PATCH v2 2/2] kfence: allow change number of object by early parameter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a5937489d22f450eaecca610d8aef6c9@honor.com>
Date: Fri, 19 Dec 2025 04:36:01 +0000
From: yuanlinyu <yuanlinyu@...or.com>
To: Marco Elver <elver@...gle.com>
CC: Alexander Potapenko <glider@...gle.com>, Dmitry Vyukov
	<dvyukov@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Huacai Chen
	<chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>,
	"kasan-dev@...glegroups.com" <kasan-dev@...glegroups.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, "loongarch@...ts.linux.dev"
	<loongarch@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 2/2] kfence: allow change number of object by early
 parameter

> From: Marco Elver <elver@...gle.com>
> Sent: Thursday, December 18, 2025 6:24 PM
> To: yuanlinyu <yuanlinyu@...or.com>
> Cc: Alexander Potapenko <glider@...gle.com>; Dmitry Vyukov
> <dvyukov@...gle.com>; Andrew Morton <akpm@...ux-foundation.org>;
> Huacai Chen <chenhuacai@...nel.org>; WANG Xuerui <kernel@...0n.name>;
> kasan-dev@...glegroups.com; linux-mm@...ck.org; loongarch@...ts.linux.dev;
> linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v2 2/2] kfence: allow change number of object by early
> parameter
> 
> On Thu, 18 Dec 2025 at 11:18, yuanlinyu <yuanlinyu@...or.com> wrote:
> >
> > > From: Marco Elver <elver@...gle.com>
> > Do you mean performance critical by access global data ?
> > It already access __kfence_pool global data.
> > Add one more global data acceptable here ?
> >
> > Other place may access global data indeed ?
> 
> is_kfence_address() is used in the slub fast path, and another load is
> one more instruction in the fast path. We have avoided this thus far
> for this reason.
> 
> > I don't know if all linux release like ubuntu enable kfence or not.
> > I only know it turn on default on android device.
> 
> This is irrelevant.
> 
> > > While I think the change itself would be useful to have eventually, a
> > > better design might be needed. It's unclear to me what the perf impact
> >
> > Could you share the better design idea ?
> 
> Hot-patchable constants, similar to static branches/jump labels. This
> had been discussed in the past (can't find the link now), but it's not
> trivial to implement unfortunately.

is it possible add tag to kfence address and only check address itself ?

> 
> An option that would enable/disable the command-line changeable number
> of objects, i.e one version that avoids the load in the fast path and
> one version that enables all the bits that you added here. But I'd
> rather avoid this if possible.

Yes, it should avoid, the purpose is without compile the kernel.

> 
> As such, please do benchmark and analyze the generated code in the
> allocator fast path (you should see a load to the new global you
> added). llvm-mca [1] might help you with analysis.
> 
> [1] https://llvm.org/docs/CommandGuide/llvm-mca.html

Thanks, will learn it