[v2,2/6] module: move finished_loading()
Commit Message
This has no functional change, just moves a routine earlier
as we'll make use of it next.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
kernel/module/main.c | 42 +++++++++++++++++++++---------------------
1 file changed, 21 insertions(+), 21 deletions(-)
Comments
On 05.04.23 04:26, Luis Chamberlain wrote:
> This has no functional change, just moves a routine earlier
> as we'll make use of it next.
>
> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> ---
I'd simply squash into #3, as that's short enough that the move doesn't
add significant noise. Anyhow:
Reviewed-by: David Hildenbrand <david@redhat.com>
On Wed, Apr 05, 2023 at 07:06:35PM +0200, David Hildenbrand wrote:
> On 05.04.23 04:26, Luis Chamberlain wrote:
> > This has no functional change, just moves a routine earlier
> > as we'll make use of it next.
> >
> > Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> > ---
>
> I'd simply squash into #3, as that's short enough that the move doesn't add
> significant noise. Anyhow:
I'll fold that, thanks.
> Reviewed-by: David Hildenbrand <david@redhat.com>
What would be *really* nice, if you can, is an output of the new module
debugfs stats on your big system. It would be nice to also see the stats
if you revert the patch "module: avoid allocation if module is already present
and ready".
The delta between those stats should give us a more realistic analysis
of probable savings due to that patch on virtual memory on bootup on a
large system. In particular the delta between "Virtual mem wasted bytes".
Luis
@@ -2454,27 +2454,6 @@ static int post_relocation(struct module *mod, const struct load_info *info)
return module_finalize(info->hdr, info->sechdrs, mod);
}
-/* Is this module of this name done loading? No locks held. */
-static bool finished_loading(const char *name)
-{
- struct module *mod;
- bool ret;
-
- /*
- * The module_mutex should not be a heavily contended lock;
- * if we get the occasional sleep here, we'll go an extra iteration
- * in the wait_event_interruptible(), which is harmless.
- */
- sched_annotate_sleep();
- mutex_lock(&module_mutex);
- mod = find_module_all(name, strlen(name), true);
- ret = !mod || mod->state == MODULE_STATE_LIVE
- || mod->state == MODULE_STATE_GOING;
- mutex_unlock(&module_mutex);
-
- return ret;
-}
-
/* Call module constructors. */
static void do_mod_ctors(struct module *mod)
{
@@ -2638,6 +2617,27 @@ static int may_init_module(void)
return 0;
}
+/* Is this module of this name done loading? No locks held. */
+static bool finished_loading(const char *name)
+{
+ struct module *mod;
+ bool ret;
+
+ /*
+ * The module_mutex should not be a heavily contended lock;
+ * if we get the occasional sleep here, we'll go an extra iteration
+ * in the wait_event_interruptible(), which is harmless.
+ */
+ sched_annotate_sleep();
+ mutex_lock(&module_mutex);
+ mod = find_module_all(name, strlen(name), true);
+ ret = !mod || mod->state == MODULE_STATE_LIVE
+ || mod->state == MODULE_STATE_GOING;
+ mutex_unlock(&module_mutex);
+
+ return ret;
+}
+
/*
* We try to place it in the list now to make sure it's unique before
* we dedicate too many resources. In particular, temporary percpu