[PATCH] fix printk output

[PATCH] fix printk output

[Sergei Ianovich]

Signed-off-by: Sergei Ianovich <ynvich@gmail.com>
---
 kernel/module.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/module.c b/kernel/module.c
index f5a3b1e..6f87299 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -817,7 +817,8 @@ SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
 
 	if (!(flags & O_NONBLOCK)) {
 		printk(KERN_WARNING
-		       "waiting module removal not supported: please upgrade");
+		       "waiting module removal not supported: "
+		       "please upgrade\n");
 	}
 
 	if (mutex_lock_interruptible(&module_mutex) != 0)
-- 
1.8.4.2

Re: [PATCH] fix printk output

[Hannes Frederic Sowa]

On Thu, Nov 28, 2013 at 02:03:59AM +0400, Sergei Ianovich wrote:
> Signed-off-by: Sergei Ianovich <ynvich@gmail.com>
> ---
>  kernel/module.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/module.c b/kernel/module.c
> index f5a3b1e..6f87299 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -817,7 +817,8 @@ SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
>  
>  	if (!(flags & O_NONBLOCK)) {
>  		printk(KERN_WARNING
> -		       "waiting module removal not supported: please upgrade");
> +		       "waiting module removal not supported: "
> +		       "please upgrade\n");

Please don't wrap long lines, even if they exceed the 80 line limit. It makes
grepping for them harder.

[PATCH v2] fix printk output

[Sergei Ianovich]

Signed-off-by: Sergei Ianovich <ynvich@gmail.com>
CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
 Changes v1..v2
 * 1-for-1 match between source and output lines
 * clarify warning
 * print tool name to avoid confusion with what to upgrade

 kernel/module.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/module.c b/kernel/module.c
index f5a3b1e..0e627e7 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -816,8 +816,10 @@ SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
 	name[MODULE_NAME_LEN-1] = '\0';
 
 	if (!(flags & O_NONBLOCK)) {
+		char tool[TASK_COMM_LEN];
 		printk(KERN_WARNING
-		       "waiting module removal not supported: please upgrade");
+		       "waiting module removal no longer supported\n"
+		       "please upgrade %s\n", get_task_comm(tool, current));
 	}
 
 	if (mutex_lock_interruptible(&module_mutex) != 0)
-- 
1.8.4.3

Re: [PATCH v2] fix printk output

[Rusty Russell]

Sergei Ianovich <ynvich@gmail.com> writes:
> Signed-off-by: Sergei Ianovich <ynvich@gmail.com>
> CC: Hannes Frederic Sowa <hannes@stressinduktion.org>
> ---
>  Changes v1..v2
>  * 1-for-1 match between source and output lines
>  * clarify warning
>  * print tool name to avoid confusion with what to upgrade

Hmm, the copy here is gratuitous.  Using current->comm is safe, just
possibly ambigious if someone is changing the task name at the same time.

And we really want this one line anyway:

  		printk(KERN_WARNING
 		       "%s: waiting module removal not supported: please upgrade\n",
                        current->comm);

BTW, did you actually hit this?

Thanks,
Rusty.

>  kernel/module.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index f5a3b1e..0e627e7 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -816,8 +816,10 @@ SYSCALL_DEFINE2(delete_module, const char __user *, name_user,
>  	name[MODULE_NAME_LEN-1] = '\0';
>  
>  	if (!(flags & O_NONBLOCK)) {
> +		char tool[TASK_COMM_LEN];
>  		printk(KERN_WARNING
> -		       "waiting module removal not supported: please upgrade");
> +		       "waiting module removal no longer supported\n"
> +		       "please upgrade %s\n", get_task_comm(tool, current));
>  	}
>  
>  	if (mutex_lock_interruptible(&module_mutex) != 0)
> -- 
> 1.8.4.3

Re: [PATCH v2] fix printk output

[Sergei Ianovich]

On Tue, 2013-12-10 at 15:59 +1030, Rusty Russell wrote:
> Sergei Ianovich <ynvich@gmail.com> writes:
> Hmm, the copy here is gratuitous.  Using current->comm is safe, just
> possibly ambigious if someone is changing the task name at the same time.
> 
> And we really want this one line anyway:
> 
>   		printk(KERN_WARNING
>  		       "%s: waiting module removal not supported: please upgrade\n",
>                         current->comm);

I would put tool's name in the end for clarity. Message comes from the
kernel and the kernel recommends to upgrade the tool. "%s: ..." could
make the impression that the tool recommends to upgrade the kernel.

> BTW, did you actually hit this?

# modprobe usb_storage
[  600.807274] usbcore: registered new interface driver usb-storage
# modprobe -r usb_storage
[  604.216318] waiting module removal not supported: please upgrade[
604.222164] usbcore: deregistering interface driver usb-storage
# modprobe -V
kmod version 9

I am using the latest kmod package from emdebian unstable-grip.

Re: [PATCH v2] fix printk output

[Rusty Russell]

Sergei Ianovich <ynvich@gmail.com> writes:
> On Tue, 2013-12-10 at 15:59 +1030, Rusty Russell wrote:
>> BTW, did you actually hit this?
>
> # modprobe usb_storage
> [  600.807274] usbcore: registered new interface driver usb-storage
> # modprobe -r usb_storage
> [  604.216318] waiting module removal not supported: please upgrade[
> 604.222164] usbcore: deregistering interface driver usb-storage
> # modprobe -V
> kmod version 9
>
> I am using the latest kmod package from emdebian unstable-grip.

Sorry, was off on leave.

Hmm, Lucas intimated that kmod version 11 started passing this flag
correctly.

In fact, kmod's modprobe *never* used the O_NONBLOCK
(ie. KMOD_REMOVE_NOWAIT) flag, until it was finally enforced in

commit 7ab8804448377fb6b8854f2dd288608db01bb43b
Author: Lucas De Marchi <lucas.demarchi@intel.com>
Date:   Fri Sep 20 01:30:07 2013 -0500

See: tools/modprobe.c at that commit:

        static int rmmod_do_remove_module(struct kmod_module *mod)
        {
        	const char *modname = kmod_module_get_name(mod);
        	struct kmod_list *deps, *itr;
        	int flags = 0, err;
...
        	if (force)
        		flags |= KMOD_REMOVE_FORCE;

        	err = kmod_module_remove_module(mod, flags);

Perhaps we need to just get rid of the kernel message, since we're
getting far too many false reports :(

Cheers,
Rusty.

Re: [PATCH v2] fix printk output

[Lucas De Marchi]

On Wed, Apr 23, 2014 at 2:14 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> Sergei Ianovich <ynvich@gmail.com> writes:
>> On Tue, 2013-12-10 at 15:59 +1030, Rusty Russell wrote:
>>> BTW, did you actually hit this?
>>
>> # modprobe usb_storage
>> [  600.807274] usbcore: registered new interface driver usb-storage
>> # modprobe -r usb_storage
>> [  604.216318] waiting module removal not supported: please upgrade[
>> 604.222164] usbcore: deregistering interface driver usb-storage
>> # modprobe -V
>> kmod version 9
>>
>> I am using the latest kmod package from emdebian unstable-grip.
>
> Sorry, was off on leave.
>
> Hmm, Lucas intimated that kmod version 11 started passing this flag
> correctly.

Sorry... rmmod was correctly updated but I forgot modprobe. My bad.
Then when I enforced it on libkmod, modprobe ended up doing the right
thing.

>
> In fact, kmod's modprobe *never* used the O_NONBLOCK
> (ie. KMOD_REMOVE_NOWAIT) flag, until it was finally enforced in
>
> commit 7ab8804448377fb6b8854f2dd288608db01bb43b
> Author: Lucas De Marchi <lucas.demarchi@intel.com>
> Date:   Fri Sep 20 01:30:07 2013 -0500
>
> See: tools/modprobe.c at that commit:
>
>         static int rmmod_do_remove_module(struct kmod_module *mod)
>         {
>                 const char *modname = kmod_module_get_name(mod);
>                 struct kmod_list *deps, *itr;
>                 int flags = 0, err;
> ...
>                 if (force)
>                         flags |= KMOD_REMOVE_FORCE;
>
>                 err = kmod_module_remove_module(mod, flags);
>
> Perhaps we need to just get rid of the kernel message, since we're
> getting far too many false reports :(

Now that I realize only kmod 16 has the fix... maybe. But I think this
commit could be easily backported to older versions if distros would
like to avoid the upgrade (even if they should not since latest
releases were more targeted to bug fixes). I'll try to push this or a
similar patch downstream to package maintainers.

Again, sorry about that.


Lucas De Marchi