From: Jessica Yu <jeyu@kernel.org>
To: Zhiqiang Liu <liuzhiqiang26@huawei.com>
Cc: rusty@rustcorp.com.au, kay.sievers@vrfy.org,
clabbe.montjoie@gmail.com, LKML <linux-kernel@vger.kernel.org>,
wangxiaogang3@huawei.com, zhoukang7@huawei.com,
Mingfangsen <mingfangsen@huawei.com>
Subject: Re: [PATCH v3] module: add link_flag pram in ref_module func to decide whether add usage link
Date: Wed, 11 Sep 2019 22:03:29 +0200 [thread overview]
Message-ID: <20190911200328.GC640@linux-8ccs> (raw)
In-Reply-To: <48019b31-3a74-1821-8ad3-72c9ef1219ba@huawei.com>
+++ Zhiqiang Liu [20/07/19 22:40 +0800]:
>Users can call ref_module func in their modules to construct
>relationships with other modules. However, the holders
>'/sys/module/<mod-name>/holders' of the target module donot include
>the users` module. So lsmod command misses detailed info of 'Used by'.
>
>When load module, the process is given as follows,
>load_module()
> -> mod_sysfs_setup()
> -> add_usage_links
> -> do_init_module
> -> mod->init()
>
>add_usage_links func creates holders of target modules linking to
>this module. If ref_module is called in mod->init() func, the usage
>links cannot be added.
>
>Consider that add_module_usage and add usage_link may separate, the
>link_flag pram is added in ref_module func to decide whether add usage
>link after add_module_usage. If link_flag is true, it means usage link
>of a to b's holder_dir should be created immediately after add_module_usage.
>
>V2->V3:
>- add link_flag pram in ref_module func to decide whether add usage link
>
>V1->V2:
>- remove incorrect Fixes tag
>- fix error handling of sysfs_create_link as suggested by Jessica Yu
>
>Signed-off-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
>Suggested-by: Jessica Yu <jeyu@kernel.org>
>Reviewed-by: Kang Zhou <zhoukang7@huawei.com>
>---
> include/linux/module.h | 2 +-
> kernel/module.c | 27 ++++++++++++++++++++-------
> 2 files changed, 21 insertions(+), 8 deletions(-)
>
>diff --git a/include/linux/module.h b/include/linux/module.h
>index 188998d3dca9..9ec04b9e93e8 100644
>--- a/include/linux/module.h
>+++ b/include/linux/module.h
>@@ -632,7 +632,7 @@ static inline void __module_get(struct module *module)
> #define symbol_put_addr(p) do { } while (0)
>
> #endif /* CONFIG_MODULE_UNLOAD */
>-int ref_module(struct module *a, struct module *b);
>+int ref_module(struct module *a, struct module *b, bool link_flag);
>
> /* This is a #define so the string doesn't get put in every .o file */
> #define module_name(mod) \
>diff --git a/kernel/module.c b/kernel/module.c
>index 80c7c09584cf..00e4862a8ef7 100644
>--- a/kernel/module.c
>+++ b/kernel/module.c
>@@ -837,25 +837,26 @@ static int already_uses(struct module *a, struct module *b)
> * 'b' can walk the list to see who sourced them), and of 'a'
> * targets (so 'a' can see what modules it targets).
> */
>-static int add_module_usage(struct module *a, struct module *b)
>+static struct module_use *add_module_usage(struct module *a, struct module *b)
> {
> struct module_use *use;
>
> pr_debug("Allocating new usage for %s.\n", a->name);
> use = kmalloc(sizeof(*use), GFP_ATOMIC);
> if (!use)
>- return -ENOMEM;
>+ return NULL;
>
> use->source = a;
> use->target = b;
> list_add(&use->source_list, &b->source_list);
> list_add(&use->target_list, &a->target_list);
>- return 0;
>+ return use;
> }
>
> /* Module a uses b: caller needs module_mutex() */
>-int ref_module(struct module *a, struct module *b)
>+int ref_module(struct module *a, struct module *b, bool link_flag)
> {
>+ struct module_use *use;
> int err;
>
> if (b == NULL || already_uses(a, b))
>@@ -866,9 +867,21 @@ int ref_module(struct module *a, struct module *b)
> if (err)
> return err;
>
>- err = add_module_usage(a, b);
>+ use = add_module_usage(a, b);
>+ if (!use) {
>+ module_put(b);
>+ return -ENOMEM;
>+ }
>+
>+ if (!link_flag)
>+ return 0;
>+
>+ err = sysfs_create_link(b->holders_dir, &a->mkobj.kobj, a->name);
> if (err) {
> module_put(b);
>+ list_del(&use->source_list);
>+ list_del(&use->target_list);
>+ kfree(use);
> return err;
> }
> return 0;
>@@ -1152,7 +1165,7 @@ static inline void module_unload_free(struct module *mod)
> {
> }
>
>-int ref_module(struct module *a, struct module *b)
>+int ref_module(struct module *a, struct module *b, bool link_flag)
> {
> return strong_try_module_get(b);
> }
>@@ -1407,7 +1420,7 @@ static const struct kernel_symbol *resolve_symbol(struct module *mod,
> goto getname;
> }
>
>- err = ref_module(mod, owner);
>+ err = ref_module(mod, owner, false);
Thanks a lot for pinging me. If I'm remembering correctly, we had to
do this because sysfs intialization is being done too late in
load_module(). The last time I was tinkering with a solution, I think
I was able to avoid needing this extra link_flag param by moving the
mod_sysfs_setup() call earlier in load_module(). It just looks a lot
cleaner that way, without that extra param. Have you looked into
trying that? I would prefer that solution rather than adding another
argument to ref_module().
Thanks,
Jessica
prev parent reply other threads:[~2019-09-11 20:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-20 14:40 [PATCH v3] module: add link_flag pram in ref_module func to decide whether add usage link Zhiqiang Liu
2019-09-11 3:16 ` Zhiqiang Liu
2019-09-11 20:03 ` Jessica Yu [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=20190911200328.GC640@linux-8ccs \
--to=jeyu@kernel.org \
--cc=clabbe.montjoie@gmail.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuzhiqiang26@huawei.com \
--cc=mingfangsen@huawei.com \
--cc=rusty@rustcorp.com.au \
--cc=wangxiaogang3@huawei.com \
--cc=zhoukang7@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.