On Sat, Dec 20, 2025 at 8:55 AM Vadim Fedorenko <[email protected]> wrote: > > On 20/12/2025 03:48, Daniel Gomez wrote: > > From: Daniel Gomez <[email protected]> > > > > The -EEXIST error code is reserved by the module loading infrastructure > > to indicate that a module is already loaded. When a module's init > > function returns -EEXIST, userspace tools like kmod interpret this as > > "module already loaded" and treat the operation as successful, returning > > 0 to the user even though the module initialization actually failed. > > > > This follows the precedent set by commit 54416fd76770 ("netfilter: > > conntrack: helper: Replace -EEXIST by -EBUSY") which fixed the same > > issue in nf_conntrack_helper_register(). > > > > This affects bpf_crypto_skcipher module. While the configuration > > required to build it as a module is unlikely in practice, it is > > technically possible, so fix it for correctness. > > > > Signed-off-by: Daniel Gomez <[email protected]> > > --- > > The error code -EEXIST is reserved by the kernel module loader to > > indicate that a module with the same name is already loaded. When a > > module's init function returns -EEXIST, kmod interprets this as "module > > already loaded" and reports success instead of failure [1]. > > > > The kernel module loader will include a safety net that provides -EEXIST > > to -EBUSY with a warning [2], and a documentation patch has been sent to > > prevent future occurrences [3]. > > > > These affected code paths were identified using a static analysis tool > > [4] that traces -EEXIST returns to module_init(). The tool was developed > > with AI assistance and all findings were manually validated. > > > > Link: https://lore.kernel.org/all/[email protected]/ [1] > > Link: > > https://lore.kernel.org/all/[email protected]/ > > [2] > > Link: > > https://lore.kernel.org/all/20251218-dev-module-init-eexists-modules-docs-v1-0-361569aa7...@samsung.com/ > > [3] > > Link: https://gitlab.com/-/snippets/4913469 [4] > > Even though I'm not quite sure that we should care once the core > module loader can adjust the error, the change looks ok to me: > > Acked-by: Vadim Fedorenko <[email protected]>
Applied to bpf-next.
