* modinfo must show real module info, not context if filename set
@ 2020-02-26 2:53 Denis Kaganovich
2020-02-26 18:31 ` Alexey Gladkov
0 siblings, 1 reply; 4+ messages in thread
From: Denis Kaganovich @ 2020-02-26 2:53 UTC (permalink / raw)
To: linux-modules
After commit e7e2cb61fa9f1db3429d91ef6accff549500d268, even if real
filename
passed - modinfo show info from context (so, I got built-in info from
running
kernel, but asking for new kernel's external module). This behaviour
unobvious
and incompatible with pre-v27. Simple use fake context for filename -
IMHO
much less ugly then current results.
Signed-off-by: Dzianis Kahanovich <mahatma@eu.by>
--- a/tools/modinfo.c 2020-02-25 13:46:38.181693570 +0300
+++ b/tools/modinfo.c 2020-02-26 05:18:39.393790919 +0300
@@ -359,7 +359,7 @@ static bool is_module_filename(const cha
static int do_modinfo(int argc, char *argv[])
{
- struct kmod_ctx *ctx;
+ struct kmod_ctx *ctx, *ctx0;
char dirname_buf[PATH_MAX];
const char *dirname = NULL;
const char *kversion = NULL;
@@ -437,7 +437,8 @@ static int do_modinfo(int argc, char *ar
}
ctx = kmod_new(dirname, &null_config);
- if (!ctx) {
+ ctx0 = kmod_new("/dev/null", &null_config);
+ if (!ctx || !ctx0) {
ERR("kmod_new() failed!\n");
return EXIT_FAILURE;
}
@@ -448,7 +449,7 @@ static int do_modinfo(int argc, char *ar
int r;
if (is_module_filename(name))
- r = modinfo_path_do(ctx, name);
+ r = modinfo_path_do(ctx0, name);
else
r = modinfo_alias_do(ctx, name);
@@ -456,6 +457,7 @@ static int do_modinfo(int argc, char *ar
err = r;
}
+ kmod_unref(ctx0);
kmod_unref(ctx);
return err >= 0 ? EXIT_SUCCESS : EXIT_FAILURE;
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: modinfo must show real module info, not context if filename set
2020-02-26 2:53 modinfo must show real module info, not context if filename set Denis Kaganovich
@ 2020-02-26 18:31 ` Alexey Gladkov
2020-02-26 19:36 ` Lucas De Marchi
0 siblings, 1 reply; 4+ messages in thread
From: Alexey Gladkov @ 2020-02-26 18:31 UTC (permalink / raw)
To: mahatma; +Cc: linux-modules
On Wed, Feb 26, 2020 at 04:53:45AM +0200, Denis Kaganovich wrote:
> After commit e7e2cb61fa9f1db3429d91ef6accff549500d268, even if real filename
> passed - modinfo show info from context (so, I got built-in info from
> running
> kernel, but asking for new kernel's external module). This behaviour
> unobvious
> and incompatible with pre-v27. Simple use fake context for filename - IMHO
> much less ugly then current results.
Can you give an example of this misbehavior ?
I have a two kernel directories (generic and current) with
modules.builtin.modinfo:
$ ls -1 /lib/modules/{5.2.0-generic,`uname -r`}/modules.builtin.modinfo
/lib/modules/5.2.0-generic/modules.builtin.modinfo
/lib/modules/5.2.0-current/modules.builtin.modinfo
The ext4 module is built into both:
$ tr '\0' '\n' < /lib/modules/`uname -r`/modules.builtin.modinfo |grep ^ext4.description
ext4.description=Fourth Extended Filesystem
$ tr '\0' '\n' < /lib/modules/5.2.0-generic/modules.builtin.modinfo |grep ^ext4.description
ext4.description=Fourth Extended Filesystem
Now I have build this module separately and put it into the tree:
$ find /lib/modules/{5.2.0-generic,`uname -r`} -name 'ext4.*'
/lib/modules/5.2.0-generic/kernel/fs/ext4/ext4.ko.gz
For current kernel:
$ tools/modinfo ext4 |grep filename
filename: (builtin)
For the other kernel:
$ tools/modinfo -k 5.2.0-generic ext4 |grep filename
filename: /lib/modules/5.2.0-generic/kernel/fs/ext4/ext4.ko.gz
Only the external module is displayed, even if there is a module with the
same name in the modules.builtin.modinfo.
I also have a very old kernel without modules.builtin.modinfo:
$ tools/modinfo -k 4.14.96-generic ext4 |grep filename
filename: /lib/modules/4.14.96-generic/kernel/fs/ext4/ext4.ko.gz
> Signed-off-by: Dzianis Kahanovich <mahatma@eu.by>
>
> --- a/tools/modinfo.c 2020-02-25 13:46:38.181693570 +0300
> +++ b/tools/modinfo.c 2020-02-26 05:18:39.393790919 +0300
> @@ -359,7 +359,7 @@ static bool is_module_filename(const cha
>
> static int do_modinfo(int argc, char *argv[])
> {
> - struct kmod_ctx *ctx;
> + struct kmod_ctx *ctx, *ctx0;
> char dirname_buf[PATH_MAX];
> const char *dirname = NULL;
> const char *kversion = NULL;
> @@ -437,7 +437,8 @@ static int do_modinfo(int argc, char *ar
> }
>
> ctx = kmod_new(dirname, &null_config);
> - if (!ctx) {
> + ctx0 = kmod_new("/dev/null", &null_config);
> + if (!ctx || !ctx0) {
> ERR("kmod_new() failed!\n");
> return EXIT_FAILURE;
> }
> @@ -448,7 +449,7 @@ static int do_modinfo(int argc, char *ar
> int r;
>
> if (is_module_filename(name))
> - r = modinfo_path_do(ctx, name);
> + r = modinfo_path_do(ctx0, name);
> else
> r = modinfo_alias_do(ctx, name);
>
> @@ -456,6 +457,7 @@ static int do_modinfo(int argc, char *ar
> err = r;
> }
>
> + kmod_unref(ctx0);
> kmod_unref(ctx);
> return err >= 0 ? EXIT_SUCCESS : EXIT_FAILURE;
> }
>
--
Rgrds, legion
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: modinfo must show real module info, not context if filename set
2020-02-26 18:31 ` Alexey Gladkov
@ 2020-02-26 19:36 ` Lucas De Marchi
2020-02-26 22:36 ` Alexey Gladkov
0 siblings, 1 reply; 4+ messages in thread
From: Lucas De Marchi @ 2020-02-26 19:36 UTC (permalink / raw)
To: Alexey Gladkov; +Cc: mahatma, linux-modules
On Wed, Feb 26, 2020 at 10:33 AM Alexey Gladkov
<gladkov.alexey@gmail.com> wrote:
>
> On Wed, Feb 26, 2020 at 04:53:45AM +0200, Denis Kaganovich wrote:
> > After commit e7e2cb61fa9f1db3429d91ef6accff549500d268, even if real filename
> > passed - modinfo show info from context (so, I got built-in info from
> > running
> > kernel, but asking for new kernel's external module). This behaviour
> > unobvious
> > and incompatible with pre-v27. Simple use fake context for filename - IMHO
> > much less ugly then current results.
>
> Can you give an example of this misbehavior ?
>
> I have a two kernel directories (generic and current) with
> modules.builtin.modinfo:
>
> $ ls -1 /lib/modules/{5.2.0-generic,`uname -r`}/modules.builtin.modinfo
> /lib/modules/5.2.0-generic/modules.builtin.modinfo
> /lib/modules/5.2.0-current/modules.builtin.modinfo
>
> The ext4 module is built into both:
>
> $ tr '\0' '\n' < /lib/modules/`uname -r`/modules.builtin.modinfo |grep ^ext4.description
> ext4.description=Fourth Extended Filesystem
>
> $ tr '\0' '\n' < /lib/modules/5.2.0-generic/modules.builtin.modinfo |grep ^ext4.description
> ext4.description=Fourth Extended Filesystem
>
> Now I have build this module separately and put it into the tree:
that's why you don't have this problem. If you just build a new
ext4.ko module and give it
in the command line without putting it into the tree, then this
problem would be triggered.
$ ~/p/kmod/tools/modinfo fs/ext4/ext4.ko
filename: /home/ldmartin/p/gfx-internal/drm-intel-internal/fs/ext4/ext4.ko
modinfo: ERROR: could not get modinfo from 'ext4': No such file or directory
$ modinfo fs/ext4/ext4.ko
filename: /home/ldmartin/p/gfx-internal/drm-intel-internal/fs/ext4/ext4.ko
softdep: pre: crc32c
license: GPL
description: Fourth Extended Filesystem
author: Remy Card, Stephen Tweedie, Andrew Morton, Andreas
Dilger, Theodore Ts'o and others
alias: fs-ext4
alias: ext3
alias: fs-ext3
alias: ext2
alias: fs-ext2
depends: mbcache,jbd2
retpoline: Y
intree: Y
name: ext4
vermagic: 5.4.17+ SMP preempt mod_unload
Lucas De Marchi
>
> $ find /lib/modules/{5.2.0-generic,`uname -r`} -name 'ext4.*'
> /lib/modules/5.2.0-generic/kernel/fs/ext4/ext4.ko.gz
>
> For current kernel:
>
> $ tools/modinfo ext4 |grep filename
> filename: (builtin)
>
> For the other kernel:
>
> $ tools/modinfo -k 5.2.0-generic ext4 |grep filename
> filename: /lib/modules/5.2.0-generic/kernel/fs/ext4/ext4.ko.gz
>
> Only the external module is displayed, even if there is a module with the
> same name in the modules.builtin.modinfo.
>
> I also have a very old kernel without modules.builtin.modinfo:
>
> $ tools/modinfo -k 4.14.96-generic ext4 |grep filename
> filename: /lib/modules/4.14.96-generic/kernel/fs/ext4/ext4.ko.gz
>
> > Signed-off-by: Dzianis Kahanovich <mahatma@eu.by>
> >
> > --- a/tools/modinfo.c 2020-02-25 13:46:38.181693570 +0300
> > +++ b/tools/modinfo.c 2020-02-26 05:18:39.393790919 +0300
> > @@ -359,7 +359,7 @@ static bool is_module_filename(const cha
> >
> > static int do_modinfo(int argc, char *argv[])
> > {
> > - struct kmod_ctx *ctx;
> > + struct kmod_ctx *ctx, *ctx0;
> > char dirname_buf[PATH_MAX];
> > const char *dirname = NULL;
> > const char *kversion = NULL;
> > @@ -437,7 +437,8 @@ static int do_modinfo(int argc, char *ar
> > }
> >
> > ctx = kmod_new(dirname, &null_config);
> > - if (!ctx) {
> > + ctx0 = kmod_new("/dev/null", &null_config);
> > + if (!ctx || !ctx0) {
> > ERR("kmod_new() failed!\n");
> > return EXIT_FAILURE;
> > }
> > @@ -448,7 +449,7 @@ static int do_modinfo(int argc, char *ar
> > int r;
> >
> > if (is_module_filename(name))
> > - r = modinfo_path_do(ctx, name);
> > + r = modinfo_path_do(ctx0, name);
> > else
> > r = modinfo_alias_do(ctx, name);
> >
> > @@ -456,6 +457,7 @@ static int do_modinfo(int argc, char *ar
> > err = r;
> > }
> >
> > + kmod_unref(ctx0);
> > kmod_unref(ctx);
> > return err >= 0 ? EXIT_SUCCESS : EXIT_FAILURE;
> > }
> >
>
> --
> Rgrds, legion
>
--
Lucas De Marchi
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: modinfo must show real module info, not context if filename set
2020-02-26 19:36 ` Lucas De Marchi
@ 2020-02-26 22:36 ` Alexey Gladkov
0 siblings, 0 replies; 4+ messages in thread
From: Alexey Gladkov @ 2020-02-26 22:36 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: mahatma, linux-modules
On Wed, Feb 26, 2020 at 11:36:00AM -0800, Lucas De Marchi wrote:
> On Wed, Feb 26, 2020 at 10:33 AM Alexey Gladkov
> <gladkov.alexey@gmail.com> wrote:
> >
> > On Wed, Feb 26, 2020 at 04:53:45AM +0200, Denis Kaganovich wrote:
> > > After commit e7e2cb61fa9f1db3429d91ef6accff549500d268, even if real filename
> > > passed - modinfo show info from context (so, I got built-in info from
> > > running
> > > kernel, but asking for new kernel's external module). This behaviour
> > > unobvious
> > > and incompatible with pre-v27. Simple use fake context for filename - IMHO
> > > much less ugly then current results.
> >
> > Can you give an example of this misbehavior ?
> >
> > I have a two kernel directories (generic and current) with
> > modules.builtin.modinfo:
> >
> > $ ls -1 /lib/modules/{5.2.0-generic,`uname -r`}/modules.builtin.modinfo
> > /lib/modules/5.2.0-generic/modules.builtin.modinfo
> > /lib/modules/5.2.0-current/modules.builtin.modinfo
> >
> > The ext4 module is built into both:
> >
> > $ tr '\0' '\n' < /lib/modules/`uname -r`/modules.builtin.modinfo |grep ^ext4.description
> > ext4.description=Fourth Extended Filesystem
> >
> > $ tr '\0' '\n' < /lib/modules/5.2.0-generic/modules.builtin.modinfo |grep ^ext4.description
> > ext4.description=Fourth Extended Filesystem
> >
> > Now I have build this module separately and put it into the tree:
>
> that's why you don't have this problem. If you just build a new
> ext4.ko module and give it
> in the command line without putting it into the tree, then this
> problem would be triggered.
Ouch, I see. The phrase "new kernel's external module" confused me because
usually the modules for the new kernel are in the tree. My bad.
> $ ~/p/kmod/tools/modinfo fs/ext4/ext4.ko
> filename: /home/ldmartin/p/gfx-internal/drm-intel-internal/fs/ext4/ext4.ko
> modinfo: ERROR: could not get modinfo from 'ext4': No such file or directory
>
> $ modinfo fs/ext4/ext4.ko
> filename: /home/ldmartin/p/gfx-internal/drm-intel-internal/fs/ext4/ext4.ko
> softdep: pre: crc32c
> license: GPL
> description: Fourth Extended Filesystem
> author: Remy Card, Stephen Tweedie, Andrew Morton, Andreas
> Dilger, Theodore Ts'o and others
> alias: fs-ext4
> alias: ext3
> alias: fs-ext3
> alias: ext2
> alias: fs-ext2
> depends: mbcache,jbd2
> retpoline: Y
> intree: Y
> name: ext4
> vermagic: 5.4.17+ SMP preempt mod_unload
>
> Lucas De Marchi
--
Rgrds, legion
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-02-26 22:36 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-26 2:53 modinfo must show real module info, not context if filename set Denis Kaganovich
2020-02-26 18:31 ` Alexey Gladkov
2020-02-26 19:36 ` Lucas De Marchi
2020-02-26 22:36 ` Alexey Gladkov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).