Re: [PATCH] kernel/params.c: make use of unused but set variable

[Rusty Russell]

Tejun Heo <htejun@xxxxxxxxx> writes:
> On Fri, Jun 12, 2015 at 10:57:24AM +0930, Rusty Russell wrote:
>> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
>> > On Sun, Jun 7, 2015 at 5:00 PM, Tejun Heo <htejun@xxxxxxxxx> wrote:
>> > At most, it could be a "WARN_ON_ONCE()". Maybe even just silently
>> > ignore the error. But BUG_ON()? Hell no.
>> 
>> Yeah, in practice it's already (1) paniced if we ran out of memory, or
>> (2) warned if we somehow tried to create two entries with the same name.
>> 
>> So the WARN_ON_ONCE() is a bit... meh.  How's this, too snarky?
>
> Sounds pretty passive agressive to me.  At least reply to the actual
> argument?

Oh.  Perhaps my sense of humour is miscalibrated.

 			err = sysfs_create_file(&mk->kobj, &vattr->mattr.attr);
+			/*
+			 * That should not fail at boot due to OOM, and it'll
+			 * already warn if we somehow get two identical names,
+			 * but this one line should quiet both gcc and lkml.
+			 */
+			WARN_ON_ONCE(err);

Oh well, I'll skip the inline commentry entirely then:

===
Subject: params: suppress unused variable error, warn once just in case code changes.

It shouldn't fail due to OOM (it's boot time), and already warns if we
get two identical names.  But you never know what the future holds, and
WARN_ON_ONCE() keeps gcc happy with minimal code.

Reported-by: Louis Langholtz <lou_langholtz@xxxxxx>
Signed-off-by: Rusty Russell <rusty@xxxxxxxxxxxxxxx>

diff --git a/kernel/params.c b/kernel/params.c
index 7edf31f2ce96..0b9bbdf830cb 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -884,6 +884,7 @@ static void __init version_sysfs_builtin(void)
 		mk = locate_module_kobject(vattr->module_name);
 		if (mk) {
 			err = sysfs_create_file(&mk->kobj, &vattr->mattr.attr);
+			WARN_ON_ONCE(err);
 			kobject_uevent(&mk->kobj, KOBJ_ADD);
 			kobject_put(&mk->kobj);
 		}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/