From: Christoph Hellwig <hch@lst.de>
To: Hou Tao <houtao1@huawei.com>
Cc: Christoph Hellwig <hch@lst.de>,
Josef Bacik <josef@toxicpanda.com>, Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, nbd@other.debian.org
Subject: Re: [PATCH v2 3/3] nbd: fix race between nbd_alloc_config() and module removal
Date: Thu, 9 Sep 2021 08:40:35 +0200 [thread overview]
Message-ID: <20210909064035.GA26290@lst.de> (raw)
In-Reply-To: <730dae5e-5af8-3554-18bf-e22ff576e2b1@huawei.com>
On Tue, Sep 07, 2021 at 11:04:16AM +0800, Hou Tao wrote:
> Let me explain first. The reason it works is due to genl_lock_all() in netlink code.
Btw, please properly format your mail. These overly long lines are really
hard to read.
> If the module removal happens before calling try_module_get(), nbd_cleanup() will
>
> call genl_unregister_family() first, and then genl_lock_all(). genl_lock_all() will
>
> prevent ops in nbd_connect_genl_ops() from being called, because the calling
>
> of nbd ops happens in genl_rcv() which needs to acquire cb_lock first.
Good.
> I have checked multiple genl_ops, it seems that the reason why these genl_ops
>
> don't need try_module_get() is that these ops don't create new object through
>
> genl_ops and just control it. However genl_family_rcv_msg_dumpit() will try to
>
> call try_module_get(), but according to the history (6dc878a8ca39 "netlink: add reference of module in netlink_dump_start"),
>
> it is because inet_diag_handler_cmd() will call __netlink_dump_start().
And now taking a step back: Why do we even need this extra module
reference? For the case where nbd_alloc_config is called from nbd_open
we obviously don't need it. In the case where it is called from
nbd_genl_connect that prevents unloading nbd when there is a configured
but not actually nbd device. Which isn't reallyed need and counter to
how other drivers work.
Did you try just removing the extra module refcounting?
next prev parent reply other threads:[~2021-09-09 6:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-04 12:25 [PATCH v2 0/3] fix races between nbd setup and module removal Hou Tao
2021-09-04 12:25 ` [PATCH v2 1/3] nbd: use pr_err to output error message Hou Tao
2021-09-06 9:27 ` Christoph Hellwig
2021-09-04 12:25 ` [PATCH v2 2/3] nbd: call genl_unregister_family() first in nbd_cleanup() Hou Tao
2021-09-06 9:27 ` Christoph Hellwig
2021-09-04 12:25 ` [PATCH v2 3/3] nbd: fix race between nbd_alloc_config() and module removal Hou Tao
2021-09-06 9:30 ` Christoph Hellwig
2021-09-06 10:08 ` Hou Tao
2021-09-06 10:25 ` Christoph Hellwig
2021-09-07 3:04 ` Hou Tao
2021-09-08 13:03 ` Hou Tao
2021-09-09 6:40 ` Christoph Hellwig [this message]
2021-09-13 4:32 ` Hou Tao
2021-09-13 15:25 ` Christoph Hellwig
2021-09-14 11:42 ` Wouter Verhelst
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=20210909064035.GA26290@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=houtao1@huawei.com \
--cc=josef@toxicpanda.com \
--cc=linux-block@vger.kernel.org \
--cc=nbd@other.debian.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;
as well as URLs for NNTP newsgroup(s).