[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ronobnl7pkbfmg3e2zc52wnq4v5l6p4sowjkg6lmlqlxgjr5va@rjrq75cnxbcl>
Date: Tue, 6 Jan 2026 09:04:20 -0600
From: Lucas De Marchi <demarchi@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: Daniel Gomez <da.gomez@...nel.org>, Lukas Wunner <lukas@...ner.de>,
Ignat Korchagin <ignat@...udflare.com>, Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>, Jarkko Sakkinen <jarkko@...nel.org>,
Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>, Luis Chamberlain <mcgrof@...nel.org>,
Petr Pavlu <petr.pavlu@...e.com>, Sami Tolvanen <samitolvanen@...gle.com>,
Aaron Tomlin <atomlin@...mlin.com>, keyrings@...r.kernel.org, linux-crypto@...r.kernel.org,
linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, Daniel Gomez <da.gomez@...sung.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] KEYS: replace -EEXIST with -EBUSY
+Greg, to consolidate from the othe thread.
On Mon, Jan 05, 2026 at 09:57:15AM +0000, David Howells wrote:
>Daniel Gomez <da.gomez@...nel.org> wrote:
>
>> From: Daniel Gomez <da.gomez@...sung.com>
>>
>> The -EEXIST error code is reserved by the module loading infrastructure
>> to indicate that a module is already loaded.
>
>EEXIST means a file exists when you're trying to create it. Granted we abuse
>that somewhat rather than add ever more error codes, but you cannot reserve it
>for indicating that a module exists.
EEXIST from [f]init_module() means "module is already loaded" and it
can't mean something else for this syscall. Other return codes are
explained in the man page, but aren't that special from the userspace
pov.
This doesn't mean we need to replace all the EBUSY throughout the call
chain with EEXIST, but the return from the syscall needs to remain
consistent if that was the case for it failing. Ideally that mapping
would come from the module init (and not from other functions it calls)
because that is the place that has that knowledge.
If a generic EBUSY->EEXIST mapping is desired, as it seems to be the
case from
https://lore.kernel.org/all/2025122212-fiction-setback-ede5@gregkh/,
then do_init_module() can do it, but in practice that means reserving 2
error codes rather than 1.
>
>> 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().
>>
>> Affected modules:
>> * pkcs8_key_parser x509_key_parser asymmetric_keys dns_resolver
>> * nvme_keyring pkcs7_test_key rxrpc turris_signing_key
>>
>> Signed-off-by: Daniel Gomez <da.gomez@...sung.com>
>
>Please don't. Userspace can always check /proc/modules (assuming procfs is
>enabled, I suppose).
EEXIST is already there with that meaning. Checking procfs (or sysfs as
kmod currently does) is racy and doesn't look like a good API - why
would userspace have to check if the module is loaded when the syscall
that loads the module failed? EEXIST is special exactly to resolve races
with 2 threads trying to load the same module.
Lucas De Marchi
>
>David
>
Powered by blists - more mailing lists