From: Niklas Cassel <cassel@kernel.org>
To: Pei Xiao <xiaopei01@kylinos.cn>
Cc: dlemoal@kernel.org, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] ata: pata_parport: pin the protocol module before device_register()
Date: Tue, 22 Sep 2026 16:53:07 +0200 [thread overview]
Message-ID: <arKWUwJeXUdGHpp0@ryzen> (raw)
In-Reply-To: <952bac5f61dc69079c3ffe62d6392bcc89f6aac0.1790047457.git.xiaopei01@kylinos.cn>
Hello Pei,
On Tue, Sep 22, 2026 at 11:38:00AM +0800, Pei Xiao wrote:
> pi_init_one() calls device_register() before try_module_get(). Between
> these two calls the device is already visible but the module is not
> pinned yet, so an unload in this window leaves pi->proto dangling:
>
> pi_init_one() rmmod -f <proto>
> --------------------------------------------------------
> device_register(&pi->dev)
> device visible on the bus
> module memory freed
> pi->proto = pr <- writes into freed memory / dangles
> try_module_get(...) <- too late, module already gone
>
> Take the module reference before registering the device, and drop it
> on the device_register() failure path.
>
> Fixes: 246a1c4c6b7f ("ata: pata_parport: add driver (PARIDE replacement)")
> Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Looking at the code, this race cannot happen.
All three callers hold pi_mutex throughout pi_init_one().
pata_parport_unregister_driver() also acquires the mutex
before unregistering.
Thus, unload cannot complete at the same time as pi_init_one().
So the motivation looks wrong.
Additionally, rmmod -f bypasses a non-zero module reference count,
so I don't see how taking a refcount earlier would solve a rmmod -f.
Are you building your kernel with CONFIG_MODULE_FORCE_UNLOAD ?
Kind regards,
Niklas
next prev parent reply other threads:[~2026-09-22 14:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 3:37 [PATCH v3 0/2] some fixes in pata_parport Pei Xiao
2026-09-22 3:38 ` [PATCH v3 1/2] ata: pata_parport: pin the protocol module before device_register() Pei Xiao
2026-09-22 14:53 ` Niklas Cassel [this message]
2026-09-23 1:17 ` Pei Xiao
2026-09-22 3:38 ` [PATCH v3 2/2] ata: pata_parport: fix parport attach idr_alloc for Pei Xiao
2026-09-22 14:55 ` Niklas Cassel
2026-09-22 14:56 ` (subset) [PATCH v3 0/2] some fixes in pata_parport Niklas Cassel
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=arKWUwJeXUdGHpp0@ryzen \
--to=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xiaopei01@kylinos.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.