linux-kernel - Re: kernel/params.c: 'err' variable "set but not used" and perhaps should be?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Jun 2015 05:22:37 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Louis Langholtz <lou_langholtz@...com>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: kernel/params.c: 'err' variable "set but not used" and perhaps
 should be?

Hello,

On Wed, Jun 03, 2015 at 01:41:40PM -0600, Louis Langholtz wrote:
> On Jun 1, 2015, at 7:32 PM, Rusty Russell <rusty@...tcorp.com.au> wrote:
> > That's hilarious.
> > 
> > __attribute__((warn_unused_result)) was added to gcc as a hack so people
> > wouldn't forget to use the realloc return, which probably seemed sane.
> > Explains why you can't suppress it by casting to void, because for
> > realloc, that would be dumb.
> > 
> > Everyone loved it so much, they sprinkled little must-check turds
> > everywhere!  Because MY FUNCTION IS IMPORTANT YOU SIMPLETON, YOU MUST
> > CHECK THE RETURN!
> > 
> > The problem with yelling "YOU MUST DO SOMETHING" is that the answer is
> > often "this is something, therefore it must be done".  That's what
> > happened here.
> 
> The function sysfs_create_file is marked as __must_check in the
> include/linux/sysfs.h file. This specific attribution appears to have been
> added to this function back on September 20, 2007 by Tejun Heo. I have CC'd
> Tejun so he has opportunity to respond to this criticism that you have raised.

Well, it's a while ago and I don't strongly object to removing it but
I still think it's a good idea to keep it around.  The failure of the
function creates a userland visible behavior difference and it's kinda
easy to forget that it may fail as it often is the final action taken
on the object.

> > @@ -853,7 +853,8 @@ 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);
> > +                       if (sysfs_create_file(&mk->kobj, &vattr->mattr.attr))
> > +                               doesnt_happen();
> >                        kobject_uevent(&mk->kobj, KOBJ_ADD);
> >                        kobject_put(&mk->kobj);
> >                }
> 
> Arguably then, the BUG_ON macro seems more appropriate for this situation
> than this suggested doesnt_happen macro or my original offering of a call to
> pr_warning.

It does happen.  If you don't wanna roll back on failure, just wrap it
in WARN_ON() so that there's at least some indication that something
failed there?  It'd kinda suck to be missing some interface files w/o
any indication, wouldn't it?

Thanks.

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