* Re: [PATCH] builtin: mark __builtin_strlen() as integer constant expression
From: Chris Li @ 2026-02-20 8:06 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Daniel Gomez, Al Viro, Sami Tolvanen, linux-sparse, Aaron Tomlin,
Dan Carpenter, Dmitry Torokhov, Eric Biggers, linux-kernel,
linux-modules, Luck, Tony, Luis Chamberlain, Petr Pavlu
In-Reply-To: <aZdighmTJN-JaijL@smile.fi.intel.com>
On Thu, Feb 19, 2026 at 11:20 AM Andy Shevchenko
<andriy.shevchenko@intel.com> wrote:
>
> On Thu, Feb 19, 2026 at 09:06:23AM -0800, Chris Li wrote:
> > On Thu, Feb 19, 2026 at 9:00 AM Daniel Gomez <da.gomez@kernel.org> wrote:
> > >
> > > Can you please take a look? If Al patch is the correct approach, any
> > > chance you can send it and fix this?
> >
> > I am asking in another thread should I pull Al's git repo instead.
> > There are a few good commits there.
>
> Please, pull Al's work, My colleagues and I use his version of sparse for a few
> weeks without noticing any downsides.
Thanks for the heads up. I just pulled Al's sparse repo.
Sorry for the delay.
Chris
^ permalink raw reply
* Re: [PATCH] builtin: mark __builtin_strlen() as integer constant expression
From: Andy Shevchenko @ 2026-02-19 19:20 UTC (permalink / raw)
To: Chris Li
Cc: Daniel Gomez, Al Viro, Sami Tolvanen, linux-sparse, Aaron Tomlin,
Dan Carpenter, Dmitry Torokhov, Eric Biggers, linux-kernel,
linux-modules, Luck, Tony, Luis Chamberlain, Petr Pavlu
In-Reply-To: <CACePvbU9Dh-caC59+L7wicZF+3sMjc4NC0HEkp9cVa7qqdydow@mail.gmail.com>
On Thu, Feb 19, 2026 at 09:06:23AM -0800, Chris Li wrote:
> On Thu, Feb 19, 2026 at 9:00 AM Daniel Gomez <da.gomez@kernel.org> wrote:
> >
> > Can you please take a look? If Al patch is the correct approach, any
> > chance you can send it and fix this?
>
> I am asking in another thread should I pull Al's git repo instead.
> There are a few good commits there.
Please, pull Al's work, My colleagues and I use his version of sparse for a few
weeks without noticing any downsides.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] builtin: mark __builtin_strlen() as integer constant expression
From: Chris Li @ 2026-02-19 17:06 UTC (permalink / raw)
To: Daniel Gomez
Cc: Al Viro, Sami Tolvanen, linux-sparse, Aaron Tomlin,
Andy Shevchenko, Dan Carpenter, Dmitry Torokhov, Eric Biggers,
linux-kernel, linux-modules, Luck, Tony, Luis Chamberlain,
Petr Pavlu
In-Reply-To: <aZdAxZR-c8PY_uEL@macos>
On Thu, Feb 19, 2026 at 9:00 AM Daniel Gomez <da.gomez@kernel.org> wrote:
>
> Chris, Al,
>
> Can you please take a look? If Al patch is the correct approach, any
> chance you can send it and fix this?
I am asking in another thread should I pull Al's git repo instead.
There are a few good commits there.
Chris
^ permalink raw reply
* Re: [PATCH 3/3] module: Add compile-time check for embedded NUL characters
From: Chris Li @ 2026-02-19 17:04 UTC (permalink / raw)
To: Luck, Tony
Cc: Dan Carpenter, Al Viro, Daniel Gomez, Sami Tolvanen, Eric Biggers,
Kees Cook, Luis Chamberlain, Rusty Russell, Petr Pavlu,
linux-modules@vger.kernel.org, Malcolm Priestley,
Mauro Carvalho Chehab, Hans Verkuil, Uwe Kleine-König,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
linux-hardening@vger.kernel.org
In-Reply-To: <aUV7kyjxlijuy5sC@agluck-desk3>
Hi Tony,
Sorry for the late reply.
On Fri, Dec 19, 2025 at 8:21 AM Luck, Tony <tony.luck@intel.com> wrote:
>
> On Fri, Dec 19, 2025 at 03:45:42PM +0300, Dan Carpenter wrote:
> > On Fri, Dec 12, 2025 at 02:30:48AM +0900, Daniel Gomez wrote:
> > > Maybe the flag fix just needs to be applied to the evaluation? Other op
> > > structs do the same. But Dan's patch did not implement evaluate. E.g.:
> > >
> > > static struct symbol_op constant_p_op = {
> > > .evaluate = evaluate_to_int_const_expr,
> > > .expand = expand_constant_p
> > > };
> > >
> >
> > I was waiting for you to send this as a patch. I can do it if you
> > need me to.
>
> Dan,
>
> Al Viro thought this was wrong. His alternative patch is here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/viro/sparse.git/commit/?id=2634e39bf02697a18fece057208150362c985992
Hi Al, should I pull from your git repo
https://git.kernel.org/pub/scm/linux/kernel/git/viro/sparse.git/
instead? I saw there is more than one commit. I assume it is ready to
pull. Please let me know if I shouldn't.
Thanks
Chris
^ permalink raw reply
* Re: [PATCH] builtin: mark __builtin_strlen() as integer constant expression
From: Daniel Gomez @ 2026-02-19 17:00 UTC (permalink / raw)
To: Chris Li, Al Viro, Sami Tolvanen
Cc: linux-sparse, Aaron Tomlin, Andy Shevchenko, Dan Carpenter,
Dmitry Torokhov, Eric Biggers, linux-kernel, linux-modules,
Luck, Tony, Luis Chamberlain, Petr Pavlu, Al Viro
In-Reply-To: <CABCJKuf8jh_yxQcR1=uMeuWOueXyoM5=L-QpTuBenRi_MZK_Gg@mail.gmail.com>
On 2026-02-19 08:41, Sami Tolvanen wrote:
> Hi Daniel,
>
> On Thu, Feb 19, 2026 at 8:11 AM Daniel Gomez <da.gomez@kernel.org> wrote:
> >
> > From: Daniel Gomez <da.gomez@samsung.com>
> >
> > Commit ae83f3b72621 ("module: Add compile-time check for embedded
> > NUL characters") in the Linux kernel added static assert checks for
> > __builtin_strlen() inside MODULE_INFO() macros. But sparse does not mark
> > the result as CEF_SET_ICE during evaluation, making these assertions
> > fail with:
> >
> > error: static assertion failed: "MODULE_INFO(...) contains embedded
> > NUL byte"
> >
> > Fix by marking __builtin_strlen() as an integer constant expression at
> > eval time. This matches other builtins like __builtin_constant_p() or
> > __builtin_safe_p().
> >
> > Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> > ---
> > Discussion:
> > https://lore.kernel.org/all/aTc9s210am0YqMV4@agluck-desk3/
>
> It looks like Al had a more complete fix for this issue, but I guess
> it never ended up in the sparse repo?
>
> https://lore.kernel.org/all/aUV7kyjxlijuy5sC@agluck-desk3/
>
> Sami
Chris, Al,
Can you please take a look? If Al patch is the correct approach, any
chance you can send it and fix this?
^ permalink raw reply
* Re: [PATCH] builtin: mark __builtin_strlen() as integer constant expression
From: Daniel Gomez @ 2026-02-19 16:53 UTC (permalink / raw)
To: Chris Li, linux-sparse
Cc: Aaron Tomlin, Andy Shevchenko, Dan Carpenter, Dmitry Torokhov,
Eric Biggers, linux-kernel, linux-modules, Luck, Tony,
Luis Chamberlain, Petr Pavlu, Sami Tolvanen
In-Reply-To: <20260219-fix-builtin-strlen-v1-1-3ec3efc0cda7@samsung.com>
On 2026-02-19 17:10, Daniel Gomez wrote:
> From: Daniel Gomez <da.gomez@samsung.com>
>
> Commit ae83f3b72621 ("module: Add compile-time check for embedded
> NUL characters") in the Linux kernel added static assert checks for
> __builtin_strlen() inside MODULE_INFO() macros. But sparse does not mark
> the result as CEF_SET_ICE during evaluation, making these assertions
> fail with:
>
> error: static assertion failed: "MODULE_INFO(...) contains embedded
> NUL byte"
>
> Fix by marking __builtin_strlen() as an integer constant expression at
> eval time. This matches other builtins like __builtin_constant_p() or
> __builtin_safe_p().
>
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: "Luck, Tony" <tony.luck@intel.com>
Reported-by: Eric Biggers <ebiggers@kernel.org>
^ permalink raw reply
* Re: [PATCH] builtin: mark __builtin_strlen() as integer constant expression
From: Sami Tolvanen @ 2026-02-19 16:41 UTC (permalink / raw)
To: Daniel Gomez
Cc: Chris Li, linux-sparse, Aaron Tomlin, Andy Shevchenko,
Dan Carpenter, Dmitry Torokhov, Eric Biggers, linux-kernel,
linux-modules, Luck, Tony, Luis Chamberlain, Petr Pavlu,
Daniel Gomez
In-Reply-To: <20260219-fix-builtin-strlen-v1-1-3ec3efc0cda7@samsung.com>
Hi Daniel,
On Thu, Feb 19, 2026 at 8:11 AM Daniel Gomez <da.gomez@kernel.org> wrote:
>
> From: Daniel Gomez <da.gomez@samsung.com>
>
> Commit ae83f3b72621 ("module: Add compile-time check for embedded
> NUL characters") in the Linux kernel added static assert checks for
> __builtin_strlen() inside MODULE_INFO() macros. But sparse does not mark
> the result as CEF_SET_ICE during evaluation, making these assertions
> fail with:
>
> error: static assertion failed: "MODULE_INFO(...) contains embedded
> NUL byte"
>
> Fix by marking __builtin_strlen() as an integer constant expression at
> eval time. This matches other builtins like __builtin_constant_p() or
> __builtin_safe_p().
>
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> ---
> Discussion:
> https://lore.kernel.org/all/aTc9s210am0YqMV4@agluck-desk3/
It looks like Al had a more complete fix for this issue, but I guess
it never ended up in the sparse repo?
https://lore.kernel.org/all/aUV7kyjxlijuy5sC@agluck-desk3/
Sami
^ permalink raw reply
* [PATCH] builtin: mark __builtin_strlen() as integer constant expression
From: Daniel Gomez @ 2026-02-19 16:10 UTC (permalink / raw)
To: Chris Li, linux-sparse
Cc: Aaron Tomlin, Andy Shevchenko, Dan Carpenter, Daniel Gomez,
Dmitry Torokhov, Eric Biggers, linux-kernel, linux-modules,
Luck, Tony, Luis Chamberlain, Petr Pavlu, Sami Tolvanen,
Daniel Gomez
From: Daniel Gomez <da.gomez@samsung.com>
Commit ae83f3b72621 ("module: Add compile-time check for embedded
NUL characters") in the Linux kernel added static assert checks for
__builtin_strlen() inside MODULE_INFO() macros. But sparse does not mark
the result as CEF_SET_ICE during evaluation, making these assertions
fail with:
error: static assertion failed: "MODULE_INFO(...) contains embedded
NUL byte"
Fix by marking __builtin_strlen() as an integer constant expression at
eval time. This matches other builtins like __builtin_constant_p() or
__builtin_safe_p().
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
Discussion:
https://lore.kernel.org/all/aTc9s210am0YqMV4@agluck-desk3/
---
builtin.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin.c b/builtin.c
index 9149c43d..7573abf8 100644
--- a/builtin.c
+++ b/builtin.c
@@ -616,6 +616,7 @@ static int expand_strlen(struct expression *expr, int cost)
}
static struct symbol_op strlen_op = {
+ .evaluate = evaluate_to_int_const_expr,
.expand = expand_strlen,
};
---
base-commit: fbdde3127b83e6d09e0ba808d7925dd84407f3c6
change-id: 20260219-fix-builtin-strlen-08eb3a02609b
Best regards,
--
Daniel Gomez <da.gomez@samsung.com>
^ permalink raw reply related
* Re: [PATCH v4 15/17] module: Introduce hash-based integrity checking
From: Nicolas Schier @ 2026-02-19 14:27 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Petr Pavlu, Nathan Chancellor, Arnd Bergmann, Luis Chamberlain,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <28cf8d51-7530-41d5-a47b-cad5ecabd269@t-8ch.de>
On Tue, Feb 03, 2026 at 01:55:05PM +0100, Thomas Weißschuh wrote:
> On 2026-01-30 18:06:20+0100, Petr Pavlu wrote:
> > On 1/13/26 1:28 PM, Thomas Weißschuh wrote:
> > > Normally the .ko module files depend on a fully built vmlinux to be
> > > available for modpost validation and BTF generation. With
> > > CONFIG_MODULE_HASHES, vmlinux now depends on the modules
> > > to build a merkle tree. This introduces a dependency cycle which is
> > > impossible to satisfy. Work around this by building the modules during
> > > link-vmlinux.sh, after vmlinux is complete enough for modpost and BTF
> > > but before the final module hashes are
> >
> > I wonder if this dependency cycle could be resolved by utilizing the
> > split into vmlinux.unstripped and vmlinux that occurred last year.
> >
> > The idea is to create the following ordering: vmlinux.unstripped ->
> > modules -> vmlinux, and to patch in .module_hashes only when building
> > the final vmlinux.
> >
> > This would require the following:
> > * Split scripts/Makefile.vmlinux into two Makefiles, one that builds the
> > current vmlinux.unstripped and the second one that builds the final
> > vmlinux from it.
> > * Modify the top Makefile to recognize vmlinux.unstripped and update the
> > BTF generation rule 'modules: vmlinux' to
> > 'modules: vmlinux.unstripped'.
> > * Add the 'vmlinux: modules' ordering in the top Makefile for
> > CONFIG_MODULE_HASHES=y.
> > * Remove the patching of vmlinux.unstripped in scripts/link-vmlinux.sh
> > and instead move it into scripts/Makefile.vmlinux when running objcopy
> > to produce the final vmlinux.
> >
> > I think this approach has two main advantages:
> > * CONFIG_MODULE_HASHES can be made orthogonal to
> > CONFIG_DEBUG_INFO_BTF_MODULES.
> > * All dependencies are expressed at the Makefile level instead of having
> > scripts/link-vmlinux.sh invoke 'make -f Makefile modules'.
> >
> > Below is a rough prototype that applies on top of this series. It is a
> > bit verbose due to the splitting of part of scripts/Makefile.vmlinux
> > into scripts/Makefile.vmlinux_unstripped.
>
> That looks like a feasible alternative. Before adopting it, I'd like to
> hear the preference of the kbuild folks.
>
> > diff --git a/Makefile b/Makefile
> > index 841772a5a260..19a3beb82fa7 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1259,7 +1259,7 @@ vmlinux_o: vmlinux.a $(KBUILD_VMLINUX_LIBS)
> > vmlinux.o modules.builtin.modinfo modules.builtin: vmlinux_o
> > @:
> >
> > -PHONY += vmlinux
> > +PHONY += vmlinux.unstripped vmlinux
> > # LDFLAGS_vmlinux in the top Makefile defines linker flags for the top vmlinux,
> > # not for decompressors. LDFLAGS_vmlinux in arch/*/boot/compressed/Makefile is
> > # unrelated; the decompressors just happen to have the same base name,
> > @@ -1270,9 +1270,11 @@ PHONY += vmlinux
> > # https://savannah.gnu.org/bugs/?61463
> > # For Make > 4.4, the following simple code will work:
> > # vmlinux: private export LDFLAGS_vmlinux := $(LDFLAGS_vmlinux)
> > -vmlinux: private _LDFLAGS_vmlinux := $(LDFLAGS_vmlinux)
> > -vmlinux: export LDFLAGS_vmlinux = $(_LDFLAGS_vmlinux)
> > -vmlinux: vmlinux.o $(KBUILD_LDS) modpost
> > +vmlinux.unstripped: private _LDFLAGS_vmlinux := $(LDFLAGS_vmlinux)
> > +vmlinux.unstripped: export LDFLAGS_vmlinux = $(_LDFLAGS_vmlinux)
> > +vmlinux.unstripped: vmlinux.o $(KBUILD_LDS) modpost
> > + $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux_unstripped
> > +vmlinux: vmlinux.unstripped
> > $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux
>
> Maybe we could keep them together in a single Makefile,
> and instead have different targets in it.
>
yes, I think so, too. I like the Petr's alternative.
Kind regards,
Nicolas
^ permalink raw reply
* Re: [PATCH v18 34/42] dept: add module support for struct dept_event_site and dept_event_site_dep
From: Petr Pavlu @ 2026-02-18 15:08 UTC (permalink / raw)
To: Byungchul Park
Cc: kernel_team, torvalds, damien.lemoal, linux-ide, adilger.kernel,
linux-ext4, mingo, peterz, will, tglx, rostedt, joel, sashal,
daniel.vetter, duyuyang, johannes.berg, tj, tytso, willy, david,
amir73il, gregkh, kernel-team, linux-mm, akpm, mhocko, minchan,
hannes, vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes,
vbabka, ngupta, linux-block, josef, linux-fsdevel, jack, jlayton,
dan.j.williams, hch, djwong, dri-devel, rodrigosiqueiramelo,
melissa.srw, hamohammed.sa, harry.yoo, chris.p.wilson,
gwan-gyeong.mun, max.byungchul.park, boqun.feng, longman,
yunseong.kim, ysk, yeoreum.yun, netdev, matthew.brost, her0gyugyu,
corbet, catalin.marinas, bp, x86, hpa, luto, sumit.semwal,
gustavo, christian.koenig, andi.shyti, arnd, lorenzo.stoakes,
Liam.Howlett, rppt, surenb, mcgrof, da.gomez, samitolvanen,
paulmck, frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux,
linux-kernel
In-Reply-To: <20260213055006.GA55430@system.software.com>
On 2/13/26 6:50 AM, Byungchul Park wrote:
> On Wed, Jan 07, 2026 at 01:19:00PM +0100, Petr Pavlu wrote:
>> On 12/5/25 8:18 AM, Byungchul Park wrote:
>>> struct dept_event_site and struct dept_event_site_dep have been
>>> introduced to track dependencies between multi event sites for a single
>>> wait, that will be loaded to data segment. Plus, a custom section,
>>> '.dept.event_sites', also has been introduced to keep pointers to the
>>> objects to make sure all the event sites defined exist in code.
>>>
>>> dept should work with the section and segment of module. Add the
>>> support to handle the section and segment properly whenever modules are
>>> loaded and unloaded.
>>>
>>> Signed-off-by: Byungchul Park <byungchul@sk.com>
>>
>> Below are a few comments from the module loader perspective.
>
> Sorry about the late reply. I've been going through some major life
> changes lately. :(
>
> Thank you sooooo~ much for your helpful feedback. I will leave my
> opinion below.
>
[...]
>>> diff --git a/kernel/dependency/dept.c b/kernel/dependency/dept.c
>>> index b14400c4f83b..07d883579269 100644
>>> --- a/kernel/dependency/dept.c
>>> +++ b/kernel/dependency/dept.c
>>> @@ -984,6 +984,9 @@ static void bfs(void *root, struct bfs_ops *ops, void *in, void **out)
>>> * event sites.
>>> */
>>>
>>> +static LIST_HEAD(dept_event_sites);
>>> +static LIST_HEAD(dept_event_site_deps);
>>> +
>>> /*
>>> * Print all events in the circle.
>>> */
>>> @@ -2043,6 +2046,33 @@ static void del_dep_rcu(struct rcu_head *rh)
>>> preempt_enable();
>>> }
>>>
>>> +/*
>>> + * NOTE: Must be called with dept_lock held.
>>> + */
>>> +static void disconnect_event_site_dep(struct dept_event_site_dep *esd)
>>> +{
>>> + list_del_rcu(&esd->dep_node);
>>> + list_del_rcu(&esd->dep_rev_node);
>>> +}
>>> +
>>> +/*
>>> + * NOTE: Must be called with dept_lock held.
>>> + */
>>> +static void disconnect_event_site(struct dept_event_site *es)
>>> +{
>>> + struct dept_event_site_dep *esd, *next_esd;
>>> +
>>> + list_for_each_entry_safe(esd, next_esd, &es->dep_head, dep_node) {
>>> + list_del_rcu(&esd->dep_node);
>>> + list_del_rcu(&esd->dep_rev_node);
>>> + }
>>> +
>>> + list_for_each_entry_safe(esd, next_esd, &es->dep_rev_head, dep_rev_node) {
>>> + list_del_rcu(&esd->dep_node);
>>> + list_del_rcu(&esd->dep_rev_node);
>>> + }
>>> +}
>>> +
>>> /*
>>> * NOTE: Must be called with dept_lock held.
>>> */
>>> @@ -2384,6 +2414,8 @@ void dept_free_range(void *start, unsigned int sz)
>>> {
>>> struct dept_task *dt = dept_task();
>>> struct dept_class *c, *n;
>>> + struct dept_event_site_dep *esd, *next_esd;
>>> + struct dept_event_site *es, *next_es;
>>> unsigned long flags;
>>>
>>> if (unlikely(!dept_working()))
>>> @@ -2405,6 +2437,24 @@ void dept_free_range(void *start, unsigned int sz)
>>> while (unlikely(!dept_lock()))
>>> cpu_relax();
>>>
>>> + list_for_each_entry_safe(esd, next_esd, &dept_event_site_deps, all_node) {
>>> + if (!within((void *)esd, start, sz))
>>> + continue;
>>> +
>>> + disconnect_event_site_dep(esd);
>>> + list_del(&esd->all_node);
>>> + }
>>> +
>>> + list_for_each_entry_safe(es, next_es, &dept_event_sites, all_node) {
>>> + if (!within((void *)es, start, sz) &&
>>> + !within(es->name, start, sz) &&
>>> + !within(es->func_name, start, sz))
>>> + continue;
>>> +
>>> + disconnect_event_site(es);
>>> + list_del(&es->all_node);
>>> + }
>>> +
>>> list_for_each_entry_safe(c, n, &dept_classes, all_node) {
>>> if (!within((void *)c->key, start, sz) &&
>>> !within(c->name, start, sz))
>>> @@ -3337,6 +3387,7 @@ void __dept_recover_event(struct dept_event_site_dep *esd,
>>>
>>> list_add(&esd->dep_node, &es->dep_head);
>>> list_add(&esd->dep_rev_node, &rs->dep_rev_head);
>>> + list_add(&esd->all_node, &dept_event_site_deps);
>>> check_recover_dl_bfs(esd);
>>> unlock:
>>> dept_unlock();
>>> @@ -3347,6 +3398,23 @@ EXPORT_SYMBOL_GPL(__dept_recover_event);
>>>
>>> #define B2KB(B) ((B) / 1024)
>>>
>>> +void dept_mark_event_site_used(void *start, void *end)
>>
>> Nit: I suggest that dept_mark_event_site_used() take pointers to
>> dept_event_site_init, which would catch the type mismatch with
>
> IMO, this is the easiest way to get all the pointers from start to the
> end, or I can't get the number of the pointers. It's similar to the
> initcalls section for device drivers.
This was a minor suggestion.. The idea is to simply change the function
signature to:
void dept_mark_event_site_used(struct dept_event_site_init **start,
struct dept_event_site_init **end))
This way, the compiler can provide proper type checking to ensure that
correct pointers are passed to dept_mark_event_site_used(). It would
catch the type mismatch with module::dept_event_sites.
>
>> module::dept_event_sites.
>>
>>> +{
>>> + struct dept_event_site_init **evtinitpp;
>>> +
>>> + for (evtinitpp = (struct dept_event_site_init **)start;
>>> + evtinitpp < (struct dept_event_site_init **)end;
>>> + evtinitpp++) {
>>> + (*evtinitpp)->evt_site->used = true;
>>> + (*evtinitpp)->evt_site->func_name = (*evtinitpp)->func_name;
>>> + list_add(&(*evtinitpp)->evt_site->all_node, &dept_event_sites);
>>> +
>>> + pr_info("dept_event_site %s@%s is initialized.\n",
>>> + (*evtinitpp)->evt_site->name,
>>> + (*evtinitpp)->evt_site->func_name);
>>> + }
>>> +}
>>> +
>>> extern char __dept_event_sites_start[], __dept_event_sites_end[];
>>
>> Related to the above, __dept_event_sites_start and
>> __dept_event_sites_end can already be properly typed here.
>
> How can I get the number of the pointers?
Similarly here, changing the code to:
extern struct dept_event_site_init *__dept_event_sites_start[], *__dept_event_sites_end[];
It is the same for the initcalls you mentioned. The declarations of
their start/end symbols are also already properly typed as
initcall_entry_t[] in include/linux/init.h.
--
Thanks,
Petr
^ permalink raw reply
* Re: [PATCH 3/3] module: Add compile-time check for embedded NUL characters
From: Dmitry Torokhov @ 2026-02-18 6:50 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Luck, Tony, Dan Carpenter, Al Viro, Daniel Gomez, Sami Tolvanen,
Chris Li, Eric Biggers, Kees Cook, Luis Chamberlain,
Rusty Russell, Petr Pavlu, linux-modules@vger.kernel.org,
Malcolm Priestley, Mauro Carvalho Chehab, Hans Verkuil,
Uwe Kleine-König, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, linux-hardening@vger.kernel.org
In-Reply-To: <aV9vo7_turBr84bs@black.igk.intel.com>
On Thu, Jan 08, 2026 at 09:49:39AM +0100, Andy Shevchenko wrote:
> On Fri, Dec 19, 2025 at 08:21:39AM -0800, Luck, Tony wrote:
> > On Fri, Dec 19, 2025 at 03:45:42PM +0300, Dan Carpenter wrote:
> > > On Fri, Dec 12, 2025 at 02:30:48AM +0900, Daniel Gomez wrote:
> > > > Maybe the flag fix just needs to be applied to the evaluation? Other op
> > > > structs do the same. But Dan's patch did not implement evaluate. E.g.:
> > > >
> > > > static struct symbol_op constant_p_op = {
> > > > .evaluate = evaluate_to_int_const_expr,
> > > > .expand = expand_constant_p
> > > > };
> > >
> > > I was waiting for you to send this as a patch. I can do it if you
> > > need me to.
> >
> > Al Viro thought this was wrong. His alternative patch is here:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/viro/sparse.git/commit/?id=2634e39bf02697a18fece057208150362c985992
>
> Sparse still is PITA as of today, can we get some fix (Al's or alternative)
> ASAP to be applied and sparse tagged as 0.6.5 so the distros will pack the
> new version, please?
Any update on this?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v18 31/42] dept: assign unique dept_key to each distinct wait_for_completion() caller
From: Dirk Behme @ 2026-02-15 6:42 UTC (permalink / raw)
To: Byungchul Park, linux-kernel
Cc: kernel_team, torvalds, damien.lemoal, linux-ide, adilger.kernel,
linux-ext4, mingo, peterz, will, tglx, rostedt, joel, sashal,
daniel.vetter, duyuyang, johannes.berg, tj, tytso, willy, david,
amir73il, gregkh, kernel-team, linux-mm, akpm, mhocko, minchan,
hannes, vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes,
vbabka, ngupta, linux-block, josef, linux-fsdevel, jack, jlayton,
dan.j.williams, hch, djwong, dri-devel, rodrigosiqueiramelo,
melissa.srw, hamohammed.sa, harry.yoo, chris.p.wilson,
gwan-gyeong.mun, max.byungchul.park, boqun.feng, longman,
yunseong.kim, ysk, yeoreum.yun, netdev, matthew.brost, her0gyugyu,
corbet, catalin.marinas, bp, x86, hpa, luto, sumit.semwal,
gustavo, christian.koenig, andi.shyti, arnd, lorenzo.stoakes,
Liam.Howlett, rppt, surenb, mcgrof, petr.pavlu, da.gomez,
samitolvanen, paulmck, frederic, neeraj.upadhyay, joelagnelf,
josh, urezki, mathieu.desnoyers, jiangshanlai, qiang.zhang,
juri.lelli, vincent.guittot, dietmar.eggemann, bsegall, mgorman,
vschneid, chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy,
anna, kees, bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux
In-Reply-To: <20251205071855.72743-32-byungchul@sk.com>
On 05.12.25 08:18, Byungchul Park wrote:
> wait_for_completion() can be used at various points in the code and it's
> very hard to distinguish wait_for_completion()s between different usages.
> Using a single dept_key for all the wait_for_completion()s could trigger
> false positive reports.
>
> Assign unique dept_key to each distinct wait_for_completion() caller to
> avoid false positive reports.
>
> While at it, add a rust helper for wait_for_completion() to avoid build
> errors.
>
> Signed-off-by: Byungchul Park <byungchul@sk.com>
> ---
> include/linux/completion.h | 100 +++++++++++++++++++++++++++++++------
> kernel/sched/completion.c | 60 +++++++++++-----------
> rust/helpers/completion.c | 5 ++
> 3 files changed, 120 insertions(+), 45 deletions(-)
>
...
> diff --git a/rust/helpers/completion.c b/rust/helpers/completion.c
> index b2443262a2ae..5bae5e749def 100644
> --- a/rust/helpers/completion.c
> +++ b/rust/helpers/completion.c
> @@ -6,3 +6,8 @@ void rust_helper_init_completion(struct completion *x)
> {
> init_completion(x);
> }
> +
> +void rust_helper_wait_for_completion(struct completion *x)
Please add `__rust_helper`:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/rust/helpers/completion.c?h=next-20260213&id=1c7a6f48f7eeb3014584d2fc55fc67f0cbaeef69
Best regards
Dirk
^ permalink raw reply
* Re: [PATCH 1/2] module: expose imported namespaces via sysfs
From: Nicholas Sielicki @ 2026-02-13 20:25 UTC (permalink / raw)
To: Sami Tolvanen
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Aaron Tomlin,
Matthias Maennich, Peter Zijlstra, Jonathan Corbet, Randy Dunlap,
linux-modules, linux-kernel
In-Reply-To: <CABCJKudKtrVCUcKRFCHfAyCCA43=gni0iB4mdL5b+176Ky2UPA@mail.gmail.com>
On Fri, Feb 13, 2026, at 11:44, Sami Tolvanen wrote:
> The patches look reasonable to me, but I do wonder if examining
> imported namespaces is the best way to distinguish between module
> variants. Is looking at /sys/module/*/taint not sufficient for your
> use case?
You're right that the example in the commit message is bad; it's true that the
taint bit is strictly mutually exclusive with dmabuf support, at least for the
way that this evolved in the nvidia open module. This is a patch I had in the
back of my head for a while, and the details had become murkier since.
The actual problem I wanted to solve with this was not with dmabuf being
conditionally available on the exporter side (where the taint bit, albeit
imprecise, would have worked), but with determining whether the ioctl was
present on the import side, which was only true from 5.12 onward for uverbs
(commit bfe0cc6).
So on eg: a system with untainted nvidia-open on 5.10, it was viable to export
dmabufs from device memory, but ibv_reg_dmabuf_mr would fail at runtime because
the ioctl didn't exist yet. The workaround for my specific piece of middleware
was just to call uname and check for 5.12+ before advertising dmabuf support
back to the caller, but this left me feeling gross.
In reality, this patch doesn't solve that problem, because any system running a
new enough kernel to have this patch will already have support on both
import/export sides. But it's what made me wish this functionality existed.
Why I still hope you'll take this patch:
1. cheaply exposing module namespace imports under sysfs can be useful beyond
this specific situation. The kernel is already tracking this and validating it
for other reasons, so it's easy to also just expose it.
2. taint may not always be mutually exclusive with a module namespace import,
eg: in the case of uverbs above.
3. currently, the only way to determine whether a module speaks dmabuf at
runtime is to hardcode module-specific priors around the kernel version and/or
the taint bit, or to link proprietary vendor libraries and check for things
like CU_DEVICE_ATTRIBUTE_DMA_BUF_SUPPORTED. Exposing this under sysfs provides
a cheaper way for networking middleware (that doesn't usually allocate device
memory itself and largely wishes to just blindly plumb dmabufs fds from callers
into some importer in a vendor agnostic way) to determine what modules are
in-play during initialization:
> user@host$ grep DMA_BUF /sys/module/*/import_ns
> /sys/module/amdgpu/import_ns:DMA_BUF
> /sys/module/ib_uverbs/import_ns:DMA_BUF
Critically, it can do this check without needing to link any vendor libraries.
As an example, libfabric currently contains an enum for heterogeneous memory
types, spanning ZE/ROCM/CUDA/SYNAPSEAI/NEURON... but libfabric doesn't need to
allocate device memory itself (it is provided by the caller, hopefully as a
dmabuf), and regardless of what module exported it, all roads will eventually
lead back to a generic dmabuf fd import ioctl for the NIC.
Despite that, to prevent memory registration errors at runtime before they
happen, it needs to probe support for these memory types at initialization
time. Today, that essentially means needing to link a new proprietary vendor
library to query dmabuf export support using a vendor-specific API. But without
any existing mechanism in the kernel to query known dmabuf importers or
exporters, even a suboptimal one, this is what is done in practice.
Best,
Nicholas
^ permalink raw reply
* Re: [PATCH 1/2] module: expose imported namespaces via sysfs
From: Sami Tolvanen @ 2026-02-13 17:44 UTC (permalink / raw)
To: linux
Cc: Luis Chamberlain, Petr Pavlu, Daniel Gomez, Aaron Tomlin,
Matthias Maennich, Peter Zijlstra, Jonathan Corbet, Randy Dunlap,
linux-modules, linux-kernel
In-Reply-To: <20260108044710.33036-1-linux@opensource.nslick.com>
Hi Nicholas,
On Wed, Jan 7, 2026 at 8:47 PM Nicholas Sielicki
<linux@opensource.nslick.com> wrote:
>
> Currently, the only way for userspace to determine which symbol
> namespaces a module imports is to locate the .ko file on disk (which may
> not match the loaded module), then either parsing the binary manually
> and handling any potential compression, or shelling-out to modinfo.
>
> This is painful in cases where userspace wants to distinguish between
> module variants that share the same name but import different
> namespaces. For example, the nvidia-uvm module exists in both open and
> closed source variants; the open source version imports the DMA_BUF
> namespace while the closed source version does not, and networking
> middleware may want to initialize itself differently depending on that.
>
> Add /sys/module/*/import_ns to expose imported namespaces for loaded
> modules. The file contains one namespace per line and only exists for
> modules that import at least one namespace.
The patches look reasonable to me, but I do wonder if examining
imported namespaces is the best way to distinguish between module
variants. Is looking at /sys/module/*/taint not sufficient for your
use case?
Sami
^ permalink raw reply
* Re: [PATCH v4 14/17] lockdown: Make the relationship to MODULE_SIG a dependency
From: Nicolas Schier @ 2026-02-13 15:32 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260113-module-hashes-v4-14-0b932db9b56b@weissschuh.net>
On Tue, Jan 13, 2026 at 01:28:58PM +0100, Thomas Weißschuh wrote:
> The new hash-based module integrity checking will also be able to
> satisfy the requirements of lockdown.
> Such an alternative is not representable with "select", so use
> "depends on" instead.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> security/lockdown/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Nicolas Schier <nsc@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 11/17] module: Move lockdown check into generic module loader
From: Nicolas Schier @ 2026-02-13 15:14 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260113-module-hashes-v4-11-0b932db9b56b@weissschuh.net>
On Tue, Jan 13, 2026 at 01:28:55PM +0100, Thomas Weißschuh wrote:
> The lockdown check buried in module_sig_check() will not compose well
> with the introduction of hash-based module validation.
> Move it into module_integrity_check() which will work better.
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> kernel/module/main.c | 6 +++++-
> kernel/module/signing.c | 3 +--
> 2 files changed, 6 insertions(+), 3 deletions(-)
>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 10/17] module: Move integrity checks into dedicated function
From: Nicolas Schier @ 2026-02-13 15:09 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: Nathan Chancellor, Arnd Bergmann, Luis Chamberlain, Petr Pavlu,
Sami Tolvanen, Daniel Gomez, Paul Moore, James Morris,
Serge E. Hallyn, Jonathan Corbet, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Naveen N Rao, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Eric Snowberg, Daniel Gomez,
Aaron Tomlin, Christophe Leroy (CS GROUP), Nicolas Bouchinet,
Xiu Jianfeng, Fabian Grünbichler, Arnout Engelen,
Mattia Rizzolo, kpcyrd, Christian Heusel, Câju Mihai-Drosi,
Sebastian Andrzej Siewior, linux-kbuild, linux-kernel, linux-arch,
linux-modules, linux-security-module, linux-doc, linuxppc-dev,
linux-integrity
In-Reply-To: <20260113-module-hashes-v4-10-0b932db9b56b@weissschuh.net>
On Tue, Jan 13, 2026 at 01:28:54PM +0100, Thomas Weißschuh wrote:
> With the addition of hash-based integrity checking, the configuration
> matrix is easier to represent in a dedicated function and with explicit
> usage of IS_ENABLED().
>
> Drop the now unnecessary stub for module_sig_check().
>
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> kernel/module/internal.h | 7 -------
> kernel/module/main.c | 18 ++++++++++++++----
> 2 files changed, 14 insertions(+), 11 deletions(-)
>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
^ permalink raw reply
* Re: [PATCH v18 34/42] dept: add module support for struct dept_event_site and dept_event_site_dep
From: Byungchul Park @ 2026-02-13 5:50 UTC (permalink / raw)
To: Petr Pavlu
Cc: kernel_team, torvalds, damien.lemoal, linux-ide, adilger.kernel,
linux-ext4, mingo, peterz, will, tglx, rostedt, joel, sashal,
daniel.vetter, duyuyang, johannes.berg, tj, tytso, willy, david,
amir73il, gregkh, kernel-team, linux-mm, akpm, mhocko, minchan,
hannes, vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes,
vbabka, ngupta, linux-block, josef, linux-fsdevel, jack, jlayton,
dan.j.williams, hch, djwong, dri-devel, rodrigosiqueiramelo,
melissa.srw, hamohammed.sa, harry.yoo, chris.p.wilson,
gwan-gyeong.mun, max.byungchul.park, boqun.feng, longman,
yunseong.kim, ysk, yeoreum.yun, netdev, matthew.brost, her0gyugyu,
corbet, catalin.marinas, bp, x86, hpa, luto, sumit.semwal,
gustavo, christian.koenig, andi.shyti, arnd, lorenzo.stoakes,
Liam.Howlett, rppt, surenb, mcgrof, da.gomez, samitolvanen,
paulmck, frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux,
linux-kernel
In-Reply-To: <7afb6666-43b6-4d17-b875-e585c7a5ac99@suse.com>
On Wed, Jan 07, 2026 at 01:19:00PM +0100, Petr Pavlu wrote:
> On 12/5/25 8:18 AM, Byungchul Park wrote:
> > struct dept_event_site and struct dept_event_site_dep have been
> > introduced to track dependencies between multi event sites for a single
> > wait, that will be loaded to data segment. Plus, a custom section,
> > '.dept.event_sites', also has been introduced to keep pointers to the
> > objects to make sure all the event sites defined exist in code.
> >
> > dept should work with the section and segment of module. Add the
> > support to handle the section and segment properly whenever modules are
> > loaded and unloaded.
> >
> > Signed-off-by: Byungchul Park <byungchul@sk.com>
>
> Below are a few comments from the module loader perspective.
Sorry about the late reply. I've been going through some major life
changes lately. :(
Thank you sooooo~ much for your helpful feedback. I will leave my
opinion below.
> > ---
> > include/linux/dept.h | 14 +++++++
> > include/linux/module.h | 5 +++
> > kernel/dependency/dept.c | 79 +++++++++++++++++++++++++++++++++++-----
> > kernel/module/main.c | 15 ++++++++
> > 4 files changed, 103 insertions(+), 10 deletions(-)
> >
> > diff --git a/include/linux/dept.h b/include/linux/dept.h
> > index 44083e6651ab..c796cdceb04e 100644
> > --- a/include/linux/dept.h
> > +++ b/include/linux/dept.h
> > @@ -166,6 +166,11 @@ struct dept_event_site {
> > struct dept_event_site *bfs_parent;
> > struct list_head bfs_node;
> >
> > + /*
> > + * for linking all dept_event_site's
> > + */
> > + struct list_head all_node;
> > +
> > /*
> > * flag indicating the event is not only declared but also
> > * actually used in code
> > @@ -182,6 +187,11 @@ struct dept_event_site_dep {
> > */
> > struct list_head dep_node;
> > struct list_head dep_rev_node;
> > +
> > + /*
> > + * for linking all dept_event_site_dep's
> > + */
> > + struct list_head all_node;
> > };
> >
> > #define DEPT_EVENT_SITE_INITIALIZER(es) \
> > @@ -193,6 +203,7 @@ struct dept_event_site_dep {
> > .bfs_gen = 0, \
> > .bfs_parent = NULL, \
> > .bfs_node = LIST_HEAD_INIT((es).bfs_node), \
> > + .all_node = LIST_HEAD_INIT((es).all_node), \
> > .used = false, \
> > }
> >
> > @@ -202,6 +213,7 @@ struct dept_event_site_dep {
> > .recover_site = NULL, \
> > .dep_node = LIST_HEAD_INIT((esd).dep_node), \
> > .dep_rev_node = LIST_HEAD_INIT((esd).dep_rev_node), \
> > + .all_node = LIST_HEAD_INIT((esd).all_node), \
> > }
> >
> > struct dept_event_site_init {
> > @@ -225,6 +237,7 @@ extern void dept_init(void);
> > extern void dept_task_init(struct task_struct *t);
> > extern void dept_task_exit(struct task_struct *t);
> > extern void dept_free_range(void *start, unsigned int sz);
> > +extern void dept_mark_event_site_used(void *start, void *end);
>
> Nit: The coding style recommends not using the extern keyword with
> function declarations.
I will remove 'extern's. Thanks.
> https://www.kernel.org/doc/html/v6.19-rc4/process/coding-style.html#function-prototypes
>
> >
> > extern void dept_map_init(struct dept_map *m, struct dept_key *k, int sub_u, const char *n);
> > extern void dept_map_reinit(struct dept_map *m, struct dept_key *k, int sub_u, const char *n);
> > @@ -288,6 +301,7 @@ struct dept_event_site { };
> > #define dept_task_init(t) do { } while (0)
> > #define dept_task_exit(t) do { } while (0)
> > #define dept_free_range(s, sz) do { } while (0)
> > +#define dept_mark_event_site_used(s, e) do { } while (0)
> >
> > #define dept_map_init(m, k, su, n) do { (void)(n); (void)(k); } while (0)
> > #define dept_map_reinit(m, k, su, n) do { (void)(n); (void)(k); } while (0)
> > diff --git a/include/linux/module.h b/include/linux/module.h
> > index d80c3ea57472..29885ba91951 100644
> > --- a/include/linux/module.h
> > +++ b/include/linux/module.h
> > @@ -29,6 +29,7 @@
> > #include <linux/srcu.h>
> > #include <linux/static_call_types.h>
> > #include <linux/dynamic_debug.h>
> > +#include <linux/dept.h>
> >
> > #include <linux/percpu.h>
> > #include <asm/module.h>
> > @@ -588,6 +589,10 @@ struct module {
> > #ifdef CONFIG_DYNAMIC_DEBUG_CORE
> > struct _ddebug_info dyndbg_info;
> > #endif
> > +#ifdef CONFIG_DEPT
> > + struct dept_event_site **dept_event_sites;
> > + unsigned int num_dept_event_sites;
> > +#endif
> > } ____cacheline_aligned __randomize_layout;
> > #ifndef MODULE_ARCH_INIT
> > #define MODULE_ARCH_INIT {}
>
> My understanding is that entries in the .dept.event_sites section are
> added by the dept_event_site_used() macro and they are pointers to the
> dept_event_site_init struct, not dept_event_site.
>
> > diff --git a/kernel/dependency/dept.c b/kernel/dependency/dept.c
> > index b14400c4f83b..07d883579269 100644
> > --- a/kernel/dependency/dept.c
> > +++ b/kernel/dependency/dept.c
> > @@ -984,6 +984,9 @@ static void bfs(void *root, struct bfs_ops *ops, void *in, void **out)
> > * event sites.
> > */
> >
> > +static LIST_HEAD(dept_event_sites);
> > +static LIST_HEAD(dept_event_site_deps);
> > +
> > /*
> > * Print all events in the circle.
> > */
> > @@ -2043,6 +2046,33 @@ static void del_dep_rcu(struct rcu_head *rh)
> > preempt_enable();
> > }
> >
> > +/*
> > + * NOTE: Must be called with dept_lock held.
> > + */
> > +static void disconnect_event_site_dep(struct dept_event_site_dep *esd)
> > +{
> > + list_del_rcu(&esd->dep_node);
> > + list_del_rcu(&esd->dep_rev_node);
> > +}
> > +
> > +/*
> > + * NOTE: Must be called with dept_lock held.
> > + */
> > +static void disconnect_event_site(struct dept_event_site *es)
> > +{
> > + struct dept_event_site_dep *esd, *next_esd;
> > +
> > + list_for_each_entry_safe(esd, next_esd, &es->dep_head, dep_node) {
> > + list_del_rcu(&esd->dep_node);
> > + list_del_rcu(&esd->dep_rev_node);
> > + }
> > +
> > + list_for_each_entry_safe(esd, next_esd, &es->dep_rev_head, dep_rev_node) {
> > + list_del_rcu(&esd->dep_node);
> > + list_del_rcu(&esd->dep_rev_node);
> > + }
> > +}
> > +
> > /*
> > * NOTE: Must be called with dept_lock held.
> > */
> > @@ -2384,6 +2414,8 @@ void dept_free_range(void *start, unsigned int sz)
> > {
> > struct dept_task *dt = dept_task();
> > struct dept_class *c, *n;
> > + struct dept_event_site_dep *esd, *next_esd;
> > + struct dept_event_site *es, *next_es;
> > unsigned long flags;
> >
> > if (unlikely(!dept_working()))
> > @@ -2405,6 +2437,24 @@ void dept_free_range(void *start, unsigned int sz)
> > while (unlikely(!dept_lock()))
> > cpu_relax();
> >
> > + list_for_each_entry_safe(esd, next_esd, &dept_event_site_deps, all_node) {
> > + if (!within((void *)esd, start, sz))
> > + continue;
> > +
> > + disconnect_event_site_dep(esd);
> > + list_del(&esd->all_node);
> > + }
> > +
> > + list_for_each_entry_safe(es, next_es, &dept_event_sites, all_node) {
> > + if (!within((void *)es, start, sz) &&
> > + !within(es->name, start, sz) &&
> > + !within(es->func_name, start, sz))
> > + continue;
> > +
> > + disconnect_event_site(es);
> > + list_del(&es->all_node);
> > + }
> > +
> > list_for_each_entry_safe(c, n, &dept_classes, all_node) {
> > if (!within((void *)c->key, start, sz) &&
> > !within(c->name, start, sz))
> > @@ -3337,6 +3387,7 @@ void __dept_recover_event(struct dept_event_site_dep *esd,
> >
> > list_add(&esd->dep_node, &es->dep_head);
> > list_add(&esd->dep_rev_node, &rs->dep_rev_head);
> > + list_add(&esd->all_node, &dept_event_site_deps);
> > check_recover_dl_bfs(esd);
> > unlock:
> > dept_unlock();
> > @@ -3347,6 +3398,23 @@ EXPORT_SYMBOL_GPL(__dept_recover_event);
> >
> > #define B2KB(B) ((B) / 1024)
> >
> > +void dept_mark_event_site_used(void *start, void *end)
>
> Nit: I suggest that dept_mark_event_site_used() take pointers to
> dept_event_site_init, which would catch the type mismatch with
IMO, this is the easiest way to get all the pointers from start to the
end, or I can't get the number of the pointers. It's similar to the
initcalls section for device drivers.
> module::dept_event_sites.
>
> > +{
> > + struct dept_event_site_init **evtinitpp;
> > +
> > + for (evtinitpp = (struct dept_event_site_init **)start;
> > + evtinitpp < (struct dept_event_site_init **)end;
> > + evtinitpp++) {
> > + (*evtinitpp)->evt_site->used = true;
> > + (*evtinitpp)->evt_site->func_name = (*evtinitpp)->func_name;
> > + list_add(&(*evtinitpp)->evt_site->all_node, &dept_event_sites);
> > +
> > + pr_info("dept_event_site %s@%s is initialized.\n",
> > + (*evtinitpp)->evt_site->name,
> > + (*evtinitpp)->evt_site->func_name);
> > + }
> > +}
> > +
> > extern char __dept_event_sites_start[], __dept_event_sites_end[];
>
> Related to the above, __dept_event_sites_start and
> __dept_event_sites_end can already be properly typed here.
How can I get the number of the pointers?
> >
> > /*
> > @@ -3356,20 +3424,11 @@ extern char __dept_event_sites_start[], __dept_event_sites_end[];
> > void __init dept_init(void)
> > {
> > size_t mem_total = 0;
> > - struct dept_event_site_init **evtinitpp;
> >
> > /*
> > * dept recover dependency tracking works from now on.
> > */
> > - for (evtinitpp = (struct dept_event_site_init **)__dept_event_sites_start;
> > - evtinitpp < (struct dept_event_site_init **)__dept_event_sites_end;
> > - evtinitpp++) {
> > - (*evtinitpp)->evt_site->used = true;
> > - (*evtinitpp)->evt_site->func_name = (*evtinitpp)->func_name;
> > - pr_info("dept_event %s@%s is initialized.\n",
> > - (*evtinitpp)->evt_site->name,
> > - (*evtinitpp)->evt_site->func_name);
> > - }
> > + dept_mark_event_site_used(__dept_event_sites_start, __dept_event_sites_end);
> > dept_recover_ready = true;
> >
> > local_irq_disable();
> > diff --git a/kernel/module/main.c b/kernel/module/main.c
> > index 03ed63f2adf0..82448cdb8ed7 100644
> > --- a/kernel/module/main.c
> > +++ b/kernel/module/main.c
> > @@ -2720,6 +2720,11 @@ static int find_module_sections(struct module *mod, struct load_info *info)
> > &mod->dyndbg_info.num_classes);
> > #endif
> >
> > +#ifdef CONFIG_DEPT
> > + mod->dept_event_sites = section_objs(info, ".dept.event_sites",
> > + sizeof(*mod->dept_event_sites),
> > + &mod->num_dept_event_sites);
> > +#endif
> > return 0;
> > }
> >
> > @@ -3346,6 +3351,14 @@ static int early_mod_check(struct load_info *info, int flags)
> > return err;
> > }
> >
> > +static void dept_mark_event_site_used_module(struct module *mod)
> > +{
> > +#ifdef CONFIG_DEPT
> > + dept_mark_event_site_used(mod->dept_event_sites,
> > + mod->dept_event_sites + mod->num_dept_event_sites);
> > +#endif
> > +}
> > +
>
> It seems to me that the .dept.event_sites section can be discarded after
> the module is initialized. In this case, the section should be prefixed
> by ".init" and its address can be obtained at the point of use in
> dept_mark_event_site_used_module(), without needing to store it inside
> the module struct.
Maybe yes. I will try. Thank you.
> Additionally, what is the reason that the dept_event_site_init data is
> not stored in the .dept.event_sites section directly and it requires
> a level of indirection?
Maybe yes. I will try to store dept_event_site_init in the
.dept.event_sites section directly.
> In general, for my own understanding, I also wonder whether the check to
> determine that a dept_event_site is used needs to be done at runtime, or
> if it could be done at build time by objtool/modpost.
You are right. I picked what I'm used to the most, among all the
candidate methods. However, I will try to use a better way if you
suggest what you think it should be.
Thanks for the thorough review, Petr.
Byungchul
> > /*
> > * Allocate and load the module: note that size of section 0 is always
> > * zero, and we rely on this for optional sections.
> > @@ -3508,6 +3521,8 @@ static int load_module(struct load_info *info, const char __user *uargs,
> > /* Done! */
> > trace_module_load(mod);
> >
> > + dept_mark_event_site_used_module(mod);
> > +
> > return do_init_module(mod);
> >
> > sysfs_cleanup:
>
> --
> Thanks,
> Petr
^ permalink raw reply
* [PATCH 12/12] arm64: crypto: convert exported crypto symbol into pluggable interface for CONFIG_CRYPTO_AES_ARM64_BS crypto
From: Jay Wang @ 2026-02-12 3:21 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, linux-crypto
Cc: Jay Wang, Vegard Nossum, Nicolai Stange, Ilia Okomin,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Luis Chamberlain, Petr Pavlu, Nathan Chancellor,
Nicolas Schier, linux-arm-kernel, x86, linux-kbuild,
linux-modules
In-Reply-To: <20260212032117.9166-1-wanjay@amazon.com>
Apply Crypto API wrappers to the exported crypto symbol in
CONFIG_CRYPTO_AES_ARM64_BS-related crypto to convert them into pluggable
interface.
Signed-off-by: Jay Wang <wanjay@amazon.com>
---
arch/arm64/crypto/Makefile | 2 +-
arch/arm64/crypto/aes-neonbs-glue.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index 6053065c18cc..2c0215a09118 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -38,7 +38,7 @@ aes-ce-blk-y := aes-glue-ce.o aes-ce.o
crypto-objs-$(CONFIG_CRYPTO_AES_ARM64_NEON_BLK) += aes-neon-blk.o
aes-neon-blk-y := aes-glue-neon.o aes-neon.o
-obj-$(CONFIG_CRYPTO_AES_ARM64_BS) += aes-neon-bs.o
+crypto-objs-$(CONFIG_CRYPTO_AES_ARM64_BS) += aes-neon-bs.o
aes-neon-bs-y := aes-neonbs-core.o aes-neonbs-glue.o
# FIPS 140 kernel module
diff --git a/arch/arm64/crypto/aes-neonbs-glue.c b/arch/arm64/crypto/aes-neonbs-glue.c
index cb87c8fc66b3..42da18008614 100644
--- a/arch/arm64/crypto/aes-neonbs-glue.c
+++ b/arch/arm64/crypto/aes-neonbs-glue.c
@@ -464,5 +464,5 @@ static int __init aes_init(void)
return crypto_register_skciphers(aes_algs, ARRAY_SIZE(aes_algs));
}
-module_init(aes_init);
-module_exit(aes_exit);
+crypto_module_init(aes_init);
+crypto_module_exit(aes_exit);
--
2.47.3
^ permalink raw reply related
* [PATCH 11/12] arm64: crypto: convert exported crypto symbol into pluggable interface for CONFIG_CRYPTO_AES_ARM64_NEON_BLK crypto
From: Jay Wang @ 2026-02-12 3:21 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, linux-crypto
Cc: Jay Wang, Vegard Nossum, Nicolai Stange, Ilia Okomin,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Luis Chamberlain, Petr Pavlu, Nathan Chancellor,
Nicolas Schier, linux-arm-kernel, x86, linux-kbuild,
linux-modules
In-Reply-To: <20260212032117.9166-1-wanjay@amazon.com>
Apply Crypto API wrappers to the exported crypto symbol in
CONFIG_CRYPTO_AES_ARM64_NEON_BLK-related crypto to convert them into pluggable
interface.
Signed-off-by: Jay Wang <wanjay@amazon.com>
---
arch/arm64/crypto/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index a98342e64eb1..6053065c18cc 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -35,7 +35,7 @@ aes-ce-ccm-y := aes-ce-ccm-glue.o aes-ce-ccm-core.o
crypto-objs-$(CONFIG_CRYPTO_AES_ARM64_CE_BLK) += aes-ce-blk.o
aes-ce-blk-y := aes-glue-ce.o aes-ce.o
-obj-$(CONFIG_CRYPTO_AES_ARM64_NEON_BLK) += aes-neon-blk.o
+crypto-objs-$(CONFIG_CRYPTO_AES_ARM64_NEON_BLK) += aes-neon-blk.o
aes-neon-blk-y := aes-glue-neon.o aes-neon.o
obj-$(CONFIG_CRYPTO_AES_ARM64_BS) += aes-neon-bs.o
--
2.47.3
^ permalink raw reply related
* [PATCH 10/12] arm64: crypto: convert exported crypto symbol into pluggable interface for CONFIG_CRYPTO_AES_ARM64_CE_BLK crypto
From: Jay Wang @ 2026-02-12 3:21 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, linux-crypto
Cc: Jay Wang, Vegard Nossum, Nicolai Stange, Ilia Okomin,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Luis Chamberlain, Petr Pavlu, Nathan Chancellor,
Nicolas Schier, linux-arm-kernel, x86, linux-kbuild,
linux-modules
In-Reply-To: <20260212032117.9166-1-wanjay@amazon.com>
Apply Crypto API wrappers to the exported crypto symbol in
CONFIG_CRYPTO_AES_ARM64_CE_BLK-related crypto to convert them into pluggable
interface.
Signed-off-by: Jay Wang <wanjay@amazon.com>
---
arch/arm64/crypto/Makefile | 2 +-
arch/arm64/crypto/aes-glue.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index 710887575f2d..a98342e64eb1 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -32,7 +32,7 @@ ghash-ce-y := ghash-ce-glue.o ghash-ce-core.o
crypto-objs-$(CONFIG_CRYPTO_AES_ARM64_CE_CCM) += aes-ce-ccm.o
aes-ce-ccm-y := aes-ce-ccm-glue.o aes-ce-ccm-core.o
-obj-$(CONFIG_CRYPTO_AES_ARM64_CE_BLK) += aes-ce-blk.o
+crypto-objs-$(CONFIG_CRYPTO_AES_ARM64_CE_BLK) += aes-ce-blk.o
aes-ce-blk-y := aes-glue-ce.o aes-ce.o
obj-$(CONFIG_CRYPTO_AES_ARM64_NEON_BLK) += aes-neon-blk.o
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index 92f43e1cd097..cba1db7afd26 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -970,14 +970,14 @@ static int __init aes_init(void)
}
#ifdef USE_V8_CRYPTO_EXTENSIONS
-module_cpu_feature_match(AES, aes_init);
+crypto_module_cpu_feature_match(AES, aes_init);
EXPORT_SYMBOL_NS(ce_aes_mac_update, "CRYPTO_INTERNAL");
#else
-module_init(aes_init);
+crypto_module_init(aes_init);
EXPORT_SYMBOL(neon_aes_ecb_encrypt);
EXPORT_SYMBOL(neon_aes_cbc_encrypt);
EXPORT_SYMBOL(neon_aes_ctr_encrypt);
EXPORT_SYMBOL(neon_aes_xts_encrypt);
EXPORT_SYMBOL(neon_aes_xts_decrypt);
#endif
-module_exit(aes_exit);
+crypto_module_exit(aes_exit);
--
2.47.3
^ permalink raw reply related
* [PATCH 09/12] arm64: crypto: convert exported crypto symbol into pluggable interface for CONFIG_CRYPTO_AES_ARM64_CE_CCM crypto
From: Jay Wang @ 2026-02-12 3:21 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, linux-crypto
Cc: Jay Wang, Vegard Nossum, Nicolai Stange, Ilia Okomin,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Luis Chamberlain, Petr Pavlu, Nathan Chancellor,
Nicolas Schier, linux-arm-kernel, x86, linux-kbuild,
linux-modules
In-Reply-To: <20260212032117.9166-1-wanjay@amazon.com>
Apply Crypto API wrappers to the exported crypto symbol in
CONFIG_CRYPTO_AES_ARM64_CE_CCM-related crypto to convert them into pluggable
interface.
Signed-off-by: Jay Wang <wanjay@amazon.com>
---
arch/arm64/crypto/Makefile | 2 +-
arch/arm64/crypto/aes-ce-ccm-glue.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index 55692fc8771d..710887575f2d 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -29,7 +29,7 @@ sm4-neon-y := sm4-neon-glue.o sm4-neon-core.o
crypto-objs-$(CONFIG_CRYPTO_GHASH_ARM64_CE) += ghash-ce.o
ghash-ce-y := ghash-ce-glue.o ghash-ce-core.o
-obj-$(CONFIG_CRYPTO_AES_ARM64_CE_CCM) += aes-ce-ccm.o
+crypto-objs-$(CONFIG_CRYPTO_AES_ARM64_CE_CCM) += aes-ce-ccm.o
aes-ce-ccm-y := aes-ce-ccm-glue.o aes-ce-ccm-core.o
obj-$(CONFIG_CRYPTO_AES_ARM64_CE_BLK) += aes-ce-blk.o
diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c b/arch/arm64/crypto/aes-ce-ccm-glue.c
index db371ac051fc..650b3374ab0d 100644
--- a/arch/arm64/crypto/aes-ce-ccm-glue.c
+++ b/arch/arm64/crypto/aes-ce-ccm-glue.c
@@ -324,8 +324,8 @@ static void __exit aes_mod_exit(void)
crypto_unregister_aead(&ccm_aes_alg);
}
-module_init(aes_mod_init);
-module_exit(aes_mod_exit);
+crypto_module_init(aes_mod_init);
+crypto_module_exit(aes_mod_exit);
MODULE_DESCRIPTION("Synchronous AES in CCM mode using ARMv8 Crypto Extensions");
MODULE_AUTHOR("Ard Biesheuvel <ardb@kernel.org>");
--
2.47.3
^ permalink raw reply related
* [PATCH 08/12] arm64: crypto: convert exported crypto symbol into pluggable interface for CONFIG_CRYPTO_GHASH_ARM64_CE crypto
From: Jay Wang @ 2026-02-12 3:21 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, linux-crypto
Cc: Jay Wang, Vegard Nossum, Nicolai Stange, Ilia Okomin,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Luis Chamberlain, Petr Pavlu, Nathan Chancellor,
Nicolas Schier, linux-arm-kernel, x86, linux-kbuild,
linux-modules
In-Reply-To: <20260212032117.9166-1-wanjay@amazon.com>
Apply Crypto API wrappers to the exported crypto symbol in
CONFIG_CRYPTO_GHASH_ARM64_CE-related crypto to convert them into pluggable
interface.
Signed-off-by: Jay Wang <wanjay@amazon.com>
---
arch/arm64/crypto/Makefile | 2 +-
arch/arm64/crypto/ghash-ce-glue.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index 48042cf5bb13..55692fc8771d 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -26,7 +26,7 @@ sm4-ce-gcm-y := sm4-ce-gcm-glue.o sm4-ce-gcm-core.o
crypto-objs-$(CONFIG_CRYPTO_SM4_ARM64_NEON_BLK) += sm4-neon.o
sm4-neon-y := sm4-neon-glue.o sm4-neon-core.o
-obj-$(CONFIG_CRYPTO_GHASH_ARM64_CE) += ghash-ce.o
+crypto-objs-$(CONFIG_CRYPTO_GHASH_ARM64_CE) += ghash-ce.o
ghash-ce-y := ghash-ce-glue.o ghash-ce-core.o
obj-$(CONFIG_CRYPTO_AES_ARM64_CE_CCM) += aes-ce-ccm.o
diff --git a/arch/arm64/crypto/ghash-ce-glue.c b/arch/arm64/crypto/ghash-ce-glue.c
index 63bb9e062251..ad17a1621df7 100644
--- a/arch/arm64/crypto/ghash-ce-glue.c
+++ b/arch/arm64/crypto/ghash-ce-glue.c
@@ -528,5 +528,5 @@ static const struct cpu_feature __maybe_unused ghash_cpu_feature[] = {
};
MODULE_DEVICE_TABLE(cpu, ghash_cpu_feature);
-module_init(ghash_ce_mod_init);
-module_exit(ghash_ce_mod_exit);
+crypto_module_init(ghash_ce_mod_init);
+crypto_module_exit(ghash_ce_mod_exit);
--
2.47.3
^ permalink raw reply related
* [PATCH 07/12] arm64: crypto: convert exported crypto symbol into pluggable interface for CONFIG_CRYPTO_SM4_ARM64_NEON_BLK crypto
From: Jay Wang @ 2026-02-12 3:21 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, linux-crypto
Cc: Jay Wang, Vegard Nossum, Nicolai Stange, Ilia Okomin,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Luis Chamberlain, Petr Pavlu, Nathan Chancellor,
Nicolas Schier, linux-arm-kernel, x86, linux-kbuild,
linux-modules
In-Reply-To: <20260212032117.9166-1-wanjay@amazon.com>
Apply Crypto API wrappers to the exported crypto symbol in
CONFIG_CRYPTO_SM4_ARM64_NEON_BLK-related crypto to convert them into pluggable
interface.
Signed-off-by: Jay Wang <wanjay@amazon.com>
---
arch/arm64/crypto/Makefile | 2 +-
arch/arm64/crypto/sm4-neon-glue.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index 807994fa9a3f..48042cf5bb13 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -23,7 +23,7 @@ sm4-ce-ccm-y := sm4-ce-ccm-glue.o sm4-ce-ccm-core.o
crypto-objs-$(CONFIG_CRYPTO_SM4_ARM64_CE_GCM) += sm4-ce-gcm.o
sm4-ce-gcm-y := sm4-ce-gcm-glue.o sm4-ce-gcm-core.o
-obj-$(CONFIG_CRYPTO_SM4_ARM64_NEON_BLK) += sm4-neon.o
+crypto-objs-$(CONFIG_CRYPTO_SM4_ARM64_NEON_BLK) += sm4-neon.o
sm4-neon-y := sm4-neon-glue.o sm4-neon-core.o
obj-$(CONFIG_CRYPTO_GHASH_ARM64_CE) += ghash-ce.o
diff --git a/arch/arm64/crypto/sm4-neon-glue.c b/arch/arm64/crypto/sm4-neon-glue.c
index e944c2a2efb0..b18a6b11b3a8 100644
--- a/arch/arm64/crypto/sm4-neon-glue.c
+++ b/arch/arm64/crypto/sm4-neon-glue.c
@@ -235,8 +235,8 @@ static void __exit sm4_exit(void)
crypto_unregister_skciphers(sm4_algs, ARRAY_SIZE(sm4_algs));
}
-module_init(sm4_init);
-module_exit(sm4_exit);
+crypto_module_init(sm4_init);
+crypto_module_exit(sm4_exit);
MODULE_DESCRIPTION("SM4 ECB/CBC/CTR using ARMv8 NEON");
MODULE_ALIAS_CRYPTO("sm4-neon");
--
2.47.3
^ permalink raw reply related
* [PATCH 06/12] arm64: crypto: convert exported crypto symbol into pluggable interface for CONFIG_CRYPTO_SM4_ARM64_CE_GCM crypto
From: Jay Wang @ 2026-02-12 3:21 UTC (permalink / raw)
To: Herbert Xu, David S . Miller, linux-crypto
Cc: Jay Wang, Vegard Nossum, Nicolai Stange, Ilia Okomin,
Catalin Marinas, Will Deacon, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Luis Chamberlain, Petr Pavlu, Nathan Chancellor,
Nicolas Schier, linux-arm-kernel, x86, linux-kbuild,
linux-modules
In-Reply-To: <20260212032117.9166-1-wanjay@amazon.com>
Apply Crypto API wrappers to the exported crypto symbol in
CONFIG_CRYPTO_SM4_ARM64_CE_GCM-related crypto to convert them into pluggable
interface.
Signed-off-by: Jay Wang <wanjay@amazon.com>
---
arch/arm64/crypto/Makefile | 2 +-
arch/arm64/crypto/sm4-ce-gcm-glue.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index f17d35591ab2..807994fa9a3f 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -20,7 +20,7 @@ sm4-ce-y := sm4-ce-glue.o sm4-ce-core.o
crypto-objs-$(CONFIG_CRYPTO_SM4_ARM64_CE_CCM) += sm4-ce-ccm.o
sm4-ce-ccm-y := sm4-ce-ccm-glue.o sm4-ce-ccm-core.o
-obj-$(CONFIG_CRYPTO_SM4_ARM64_CE_GCM) += sm4-ce-gcm.o
+crypto-objs-$(CONFIG_CRYPTO_SM4_ARM64_CE_GCM) += sm4-ce-gcm.o
sm4-ce-gcm-y := sm4-ce-gcm-glue.o sm4-ce-gcm-core.o
obj-$(CONFIG_CRYPTO_SM4_ARM64_NEON_BLK) += sm4-neon.o
diff --git a/arch/arm64/crypto/sm4-ce-gcm-glue.c b/arch/arm64/crypto/sm4-ce-gcm-glue.c
index ef06f4f768a1..256a66905241 100644
--- a/arch/arm64/crypto/sm4-ce-gcm-glue.c
+++ b/arch/arm64/crypto/sm4-ce-gcm-glue.c
@@ -253,8 +253,8 @@ static const struct cpu_feature __maybe_unused sm4_ce_gcm_cpu_feature[] = {
};
MODULE_DEVICE_TABLE(cpu, sm4_ce_gcm_cpu_feature);
-module_cpu_feature_match(SM4, sm4_ce_gcm_init);
-module_exit(sm4_ce_gcm_exit);
+crypto_module_cpu_feature_match(SM4, sm4_ce_gcm_init);
+crypto_module_exit(sm4_ce_gcm_exit);
MODULE_DESCRIPTION("Synchronous SM4 in GCM mode using ARMv8 Crypto Extensions");
MODULE_ALIAS_CRYPTO("gcm(sm4)");
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox