Messages in this thread | | | Date | Tue, 27 Feb 2024 08:30:44 -0800 | From | Luis Chamberlain <> | Subject | Re: [PATCH v4] modules: wait do_free_init correctly |
| |
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
| |