All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Changbin Du <changbin.du@huawei.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
	Xiaoyi Su <suxiaoyi@huawei.com>,
	Eric Chanudet <echanude@redhat.com>,
	Luis Chamberlain <mcgrof@infradead.org>
Subject: Re: [PATCH v4] modules: wait do_free_init correctly
Date: Tue, 27 Feb 2024 08:30:44 -0800	[thread overview]
Message-ID: <Zd4ONMe5c_tdPyLW@bombadil.infradead.org> (raw)
In-Reply-To: <20240227023546.2490667-1-changbin.du@huawei.com>

On Tue, Feb 27, 2024 at 10:35:46AM +0800, Changbin Du wrote:
> The synchronization here is to ensure the ordering of freeing of a module
> init so that it happens before W+X checking. It is worth noting it is not
> that the freeing was not happening, it is just that our sanity checkers
> raced against the permission checkers which assume init memory is already
> gone.
> 
> Commit 1a7b7d922081 ("modules: Use vmalloc special flag") moved
> calling do_free_init() into a global workqueue instead of relying on it
> being called through call_rcu(..., do_free_init), which used to allowed us
> call do_free_init() asynchronously after the end of a subsequent grace
> period. The move to a global workqueue broke the gaurantees for code which
> needed to be sure the do_free_init() would complete with rcu_barrier().
> To fix this callers which used to rely on rcu_barrier() must now instead
> use flush_work(&init_free_wq).
> 
> Without this fix, we still could encounter false positive reports in W+X
> checking since the rcu_barrier() here can not ensure the ordering now.
> 
> Even worse, the rcu_barrier() can introduce significant delay. Eric Chanudet
> reported that the rcu_barrier introduces ~0.1s delay on a PREEMPT_RT kernel.
> 
>   [    0.291444] Freeing unused kernel memory: 5568K
>   [    0.402442] Run /sbin/init as init process
> 
> With this fix, the above delay can be eliminated.
> 
> Fixes: 1a7b7d922081 ("modules: Use vmalloc special flag")
> Signed-off-by: Changbin Du <changbin.du@huawei.com>
> Cc: Xiaoyi Su <suxiaoyi@huawei.com>
> Cc: Eric Chanudet <echanude@redhat.com>
> Cc: Luis Chamberlain <mcgrof@infradead.org>
> Tested-by: Eric Chanudet <echanude@redhat.com>

Acked-by: Luis Chamberlain <mcgrof@kernel.org>

  Luis

      reply	other threads:[~2024-02-27 16:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-27  2:35 [PATCH v4] modules: wait do_free_init correctly Changbin Du
2024-02-27 16:30 ` Luis Chamberlain [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=Zd4ONMe5c_tdPyLW@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=changbin.du@huawei.com \
    --cc=echanude@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=mcgrof@infradead.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 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.