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 v2] module: add usage links when calling ref_module func
Date: Tue, 9 Jul 2019 18:10:39 +0200 [thread overview]
Message-ID: <20190709161039.GA3501@linux-8ccs> (raw)
In-Reply-To: <4fec6c3b-03b8-dd57-4009-99431105a8a5@huawei.com>
+++ Zhiqiang Liu [03/07/19 10:09 +0800]:
>From: Zhiqiang Liu <liuzhiqiang26@huawei.com>
>
>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.
>
>Here, we will add usage link of a to b's holder_dir.
>
>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>
>---
> kernel/module.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
>diff --git a/kernel/module.c b/kernel/module.c
>index 80c7c09584cf..672abce2222c 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)
> {
>+ struct module_use *use;
> int err;
>
> if (b == NULL || already_uses(a, b))
>@@ -866,9 +867,18 @@ 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;
>+ }
>+
>+ err = sysfs_create_link(b->holders_dir, &a->mkobj.kobj, a->name);
Sigh. This ultimately doesn't work because in load_module(), we use
ref_module() in resolve_symbol(), and mod->mkobj.kobj doesn't get
initialized until mod_sysfs_init(), which happens much later in
load_module(). So what happens is that the ref_module(mod, owner) call
in resolve_symbol() returns an error because sysfs_create_link() fails here.
We could *maybe* move sysfs initialization earlier in load_module()
but that is an entirely untested idea and I would need to think about
that more.
> if (err) {
> module_put(b);
>+ list_del(&use->source_list);
>+ list_del(&use->target_list);
>+ kfree(use);
> return err;
> }
> return 0;
>--
>2.19.1
>
next prev parent reply other threads:[~2019-07-09 16:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-03 2:09 [PATCH v2] module: add usage links when calling ref_module func Zhiqiang Liu
2019-07-06 6:17 ` Zhiqiang Liu
2019-07-09 16:10 ` Jessica Yu [this message]
2019-07-11 6:03 ` Zhiqiang Liu
2019-07-11 9:17 ` Jessica Yu
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=20190709161039.GA3501@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.