From: Daniel Gomez <da.gomez@kernel.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Hannes Reinecke <hare@suse.de>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Petr Pavlu <petr.pavlu@suse.com>,
Sami Tolvanen <samitolvanen@google.com>,
Aaron Tomlin <atomlin@atomlin.com>,
Lucas De Marchi <demarchi@kernel.org>,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
Daniel Gomez <da.gomez@samsung.com>
Subject: Re: [PATCH 0/2] scsi: target+fcoe: replace -EEXIST with -EBUSY in module_init() paths
Date: Sun, 21 Dec 2025 11:00:00 +0100 [thread overview]
Message-ID: <9817dbc0-0bb6-4e31-8413-c54b12ce952b@kernel.org> (raw)
In-Reply-To: <6be5a2cfdeb6af71f6bd676e71418393d78e93e0.camel@HansenPartnership.com>
On 21/12/2025 05.02, James Bottomley wrote:
> On Sun, 2025-12-21 at 04:30 +0100, Daniel Gomez wrote:
>> On 20/12/2025 05.27, James Bottomley wrote:
>>> On Sat, 2025-12-20 at 04:37 +0100, Daniel Gomez wrote:
> None of that answers the why question: Given that EEXIST is used all
> over the kernel, for what appear to be fairly legitimate cases, why
> would we suddenly want it to become only for modules? I get that we
> can, as you propose patches above, but why should we bother? It seems
> to be a useful error code outside the module use case, so why the need
> to restrict it to being only for modules?
Because both the module loader and module_init() return through the same
(f)init_module() syscall path, we need to ensure consistency in what we report
back to userspace. The init_module(2) man page documents EEXIST as "a module
with this name is already loaded." When module_init() returns EEXIST for
a different reason, userspace tools following the documented behavior will
misinterpret it. We can't use the same error code for different meanings and
expect the caller to differentiate.
prev parent reply other threads:[~2025-12-21 10:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-20 3:37 [PATCH 0/2] scsi: target+fcoe: replace -EEXIST with -EBUSY in module_init() paths Daniel Gomez
2025-12-20 3:37 ` [PATCH 1/2] target: replace -EEXIST with -EBUSY Daniel Gomez
2025-12-20 3:37 ` [PATCH 2/2] scsi: fcoe: " Daniel Gomez
2025-12-20 4:27 ` [PATCH 0/2] scsi: target+fcoe: replace -EEXIST with -EBUSY in module_init() paths James Bottomley
2025-12-21 3:30 ` Daniel Gomez
2025-12-21 4:02 ` James Bottomley
2025-12-21 10:00 ` Daniel Gomez [this message]
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=9817dbc0-0bb6-4e31-8413-c54b12ce952b@kernel.org \
--to=da.gomez@kernel.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=atomlin@atomlin.com \
--cc=da.gomez@samsung.com \
--cc=demarchi@kernel.org \
--cc=hare@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mcgrof@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=samitolvanen@google.com \
--cc=target-devel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox