Re: [PATCH 3/5] Module: check to see if we have a built in module with the same name

2008-01-28 Thread Rusty Russell
On Monday 28 January 2008 10:38:40 Greg Kroah-Hartman wrote:
> When trying to load a module with the same name as a built-in one, a
> scary kobject backtrace comes up.  Prevent that from checking for this
> condition and warning the user as to what exactly is going on.
>
> Cc: Rusty Russell <[EMAIL PROTECTED]>
> Cc: Linus Torvalds <[EMAIL PROTECTED]>
> Cc: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> ---
>  kernel/module.c |   10 ++
>  1 files changed, 10 insertions(+), 0 deletions(-)

Oh, I pushed this as part of my module updates.

Unfortunately Andrew still doesn't seem to have picked up my patch queue, and 
keeps grabbing random (sometimes outdated) patches which are also in my 
tree :(

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/5] Module: check to see if we have a built in module with the same name

2008-01-28 Thread Jan Engelhardt

On Jan 27 2008 15:38, Greg Kroah-Hartman wrote:
>Subject: [PATCH 3/5] Module: check to see if we have a built in module with the
> same name
>
>When trying to load a module with the same name as a built-in one, a
>scary kobject backtrace comes up.  Prevent that from checking for this
>condition and warning the user as to what exactly is going on.

Should not external modules with internal names be rejected at modprobe 
time? Otherwise I'd wonder how you want to deal with /sys/modules/XXX if 
both modules export some module_param()s.

It's just that if I happen to load vt.ko that the existing 
/sys/modules/vt (from in-kernel vt.o) does not get overwritten by new 
dentries that vt.ko will spawn. Something like /sys/modules/vt.1 perhaps 
for /the new module with same name?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/5] Module: check to see if we have a built in module with the same name

2008-01-28 Thread Jan Engelhardt

On Jan 27 2008 15:38, Greg Kroah-Hartman wrote:
Subject: [PATCH 3/5] Module: check to see if we have a built in module with the
 same name

When trying to load a module with the same name as a built-in one, a
scary kobject backtrace comes up.  Prevent that from checking for this
condition and warning the user as to what exactly is going on.

Should not external modules with internal names be rejected at modprobe 
time? Otherwise I'd wonder how you want to deal with /sys/modules/XXX if 
both modules export some module_param()s.

It's just that if I happen to load vt.ko that the existing 
/sys/modules/vt (from in-kernel vt.o) does not get overwritten by new 
dentries that vt.ko will spawn. Something like /sys/modules/vt.1 perhaps 
for /the new module with same name?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 3/5] Module: check to see if we have a built in module with the same name

2008-01-28 Thread Rusty Russell
On Monday 28 January 2008 10:38:40 Greg Kroah-Hartman wrote:
 When trying to load a module with the same name as a built-in one, a
 scary kobject backtrace comes up.  Prevent that from checking for this
 condition and warning the user as to what exactly is going on.

 Cc: Rusty Russell [EMAIL PROTECTED]
 Cc: Linus Torvalds [EMAIL PROTECTED]
 Cc: Andrew Morton [EMAIL PROTECTED]
 Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
 ---
  kernel/module.c |   10 ++
  1 files changed, 10 insertions(+), 0 deletions(-)

Oh, I pushed this as part of my module updates.

Unfortunately Andrew still doesn't seem to have picked up my patch queue, and 
keeps grabbing random (sometimes outdated) patches which are also in my 
tree :(

Cheers,
Rusty.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3/5] Module: check to see if we have a built in module with the same name

2008-01-27 Thread Greg Kroah-Hartman
When trying to load a module with the same name as a built-in one, a
scary kobject backtrace comes up.  Prevent that from checking for this
condition and warning the user as to what exactly is going on.

Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Linus Torvalds <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
 kernel/module.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 1bb4c5e..76ddc85 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1214,6 +1214,7 @@ void module_remove_modinfo_attrs(struct module *mod)
 int mod_sysfs_init(struct module *mod)
 {
int err;
+   struct kobject *kobj;
 
if (!module_sysfs_initialized) {
printk(KERN_ERR "%s: module sysfs not initialized\n",
@@ -1221,6 +1222,15 @@ int mod_sysfs_init(struct module *mod)
err = -EINVAL;
goto out;
}
+
+   kobj = kset_find_obj(module_kset, mod->name);
+   if (kobj) {
+   printk(KERN_ERR "%s: module is already loaded\n", mod->name);
+   kobject_put(kobj);
+   err = -EINVAL;
+   goto out;
+   }
+
mod->mkobj.mod = mod;
 
memset(>mkobj.kobj, 0, sizeof(mod->mkobj.kobj));
-- 
1.5.3.8

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH 3/5] Module: check to see if we have a built in module with the same name

2008-01-27 Thread Greg Kroah-Hartman
When trying to load a module with the same name as a built-in one, a
scary kobject backtrace comes up.  Prevent that from checking for this
condition and warning the user as to what exactly is going on.

Cc: Rusty Russell [EMAIL PROTECTED]
Cc: Linus Torvalds [EMAIL PROTECTED]
Cc: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
 kernel/module.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index 1bb4c5e..76ddc85 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1214,6 +1214,7 @@ void module_remove_modinfo_attrs(struct module *mod)
 int mod_sysfs_init(struct module *mod)
 {
int err;
+   struct kobject *kobj;
 
if (!module_sysfs_initialized) {
printk(KERN_ERR %s: module sysfs not initialized\n,
@@ -1221,6 +1222,15 @@ int mod_sysfs_init(struct module *mod)
err = -EINVAL;
goto out;
}
+
+   kobj = kset_find_obj(module_kset, mod-name);
+   if (kobj) {
+   printk(KERN_ERR %s: module is already loaded\n, mod-name);
+   kobject_put(kobj);
+   err = -EINVAL;
+   goto out;
+   }
+
mod-mkobj.mod = mod;
 
memset(mod-mkobj.kobj, 0, sizeof(mod-mkobj.kobj));
-- 
1.5.3.8

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/