[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZYL7B59dQ6XFtVP8@bombadil.infradead.org>
Date: Wed, 20 Dec 2023 06:32:39 -0800
From: Luis Chamberlain <mcgrof@...nel.org>
To: Changbin Du <changbin.du@...wei.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
Hui Wang <hw.huiwang@...wei.com>, Xiaoyi Su <suxiaoyi@...wei.com>,
Jeffrey Hugo <jhugo@...eaurora.org>
Subject: Re: [PATCH] modules: wait do_free_init correctly
On Wed, Dec 20, 2023 at 01:27:51PM +0800, Changbin Du wrote:
> On Tue, Dec 19, 2023 at 01:52:03PM -0800, Luis Chamberlain wrote:
> > 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@...wei.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?
> >
> Seems the waiting was introduced by commit ae646f0b9ca ("init: fix false positives
> in W+X checking").
>
> As what I have observed, mark_readonly() is only invoked by the first user mode
> thread function kernel_init(), which is before userspace /init. So is it real
> possible we have loaded modules at this point?
Are you saying we don't free any module inits at all then? I asked a lot
of questions and your answers seem slim.
How did you find this?
What actual impact does this have without the patch?
The commit must document this.
Luis
Powered by blists - more mailing lists