Linux Modules
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Changbin Du <changbin.du@huawei.com>,
	linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
	Hui Wang <hw.huiwang@huawei.com>, Xiaoyi Su <suxiaoyi@huawei.com>
Subject: Re: [PATCH] modules: wait do_free_init correctly
Date: Tue, 19 Dec 2023 13:52:03 -0800	[thread overview]
Message-ID: <ZYIQgz+de/JQl10N@bombadil.infradead.org> (raw)
In-Reply-To: <20231219125151.4a042a259edf3c916580ccfe@linux-foundation.org>

On Tue, Dec 19, 2023 at 12:51:51PM -0800, Andrew Morton wrote:
> On Tue, 19 Dec 2023 22:12:31 +0800 Changbin Du <changbin.du@huawei.com> wrote:
> 
> > The commit 1a7b7d922081 ("modules: Use vmalloc special flag") moves
> > do_free_init() into a global workqueue instead of call_rcu(). So now
> > we should wait it via flush_work().
> 
> What are the runtime effects of this change?

Indeed that's needed given how old this culprit commit is:

git describe --contains 1a7b7d922081
v5.2-rc1~192^2~5

Who did this work and for what reason? What triggered this itch?

Is it perhaps for an out of tree driver that did something funky
on its module exit?

As per Documentation/RCU/rcubarrier.rst rcu_barrier will ensure the
callbacks complete, so interms of determinism both mechanisms will
have waited for the free. It seems we're now just limiting the scope.

This could also mean initialization grew used to having RCU calls on
init complete at this point in time, even for modules, and so localizing
this wait may now also introduce other unexpected behaviour.

  Luis

  reply	other threads:[~2023-12-19 21:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-19 14:12 [PATCH] modules: wait do_free_init correctly Changbin Du
2023-12-19 20:51 ` Andrew Morton
2023-12-19 21:52   ` Luis Chamberlain [this message]
2023-12-20  5:27     ` Changbin Du
2023-12-20 14:32       ` Luis Chamberlain
2023-12-21  2:30         ` Changbin Du
2023-12-25  4:07           ` Changbin Du

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=ZYIQgz+de/JQl10N@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=changbin.du@huawei.com \
    --cc=hw.huiwang@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=suxiaoyi@huawei.com \
    /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