linux-kernel - Re: [PATCH 1/2]drivers/usb/core/sysfs.c Fix variable 'retval' set but not used

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] [day] [month] [year] [list]

Date:	Tue, 3 Aug 2010 10:22:04 -0700
From:	Greg KH <gregkh@...e.de>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Valdis.Kletnieks@...edu,
	"Justin P. Mattock" <justinmattock@...il.com>,
	linux-usb@...r.kernel.org, dbrownell@...rs.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2]drivers/usb/core/sysfs.c Fix variable 'retval' set
 but not used

On Tue, Aug 03, 2010 at 01:09:31PM -0400, Alan Stern wrote:
> On Tue, 3 Aug 2010, Greg KH wrote:
> 
> > On Tue, Aug 03, 2010 at 11:34:26AM -0400, Alan Stern wrote:
> > > On Tue, 3 Aug 2010 Valdis.Kletnieks@...edu wrote:
> > > 
> > > > > Failure to create a file in sysfs is almost never fatal and usually not 
> > > > > even dangerous.  Ignoring the error is generally better than failing 
> > > > > the entire operation.
> > > > 
> > > > Then why the __must_check attribute if it's usually ignorable? I thought
> > > > that was reserved for functions that you damned sight better well check
> > > > for errors because bad things are afoot otherwise?
> > > 
> > > That's a good question.  Perhaps Greg KH knows the answer.
> > 
> > You should check the return value for that function.  To not do that is
> > a bug.  This one looks like it snuck through.  Fixing it properly is the
> > correct thing to do.
> 
> In other words, usb_set_configuration() should fail if 
> usb_create_sysfs_intf_files() is unable to create the attribute file 
> containing an interface's string descriptor?
> 
> And likewise, ehci_run() should fail if the "companion" and debugging 
> files can't be created?

Ah, yeah, now I recall why we didn't do anything with those values :)

It's best to continue on.  Perhaps we should just emit a warning to the
system log if the file fails to be created and move on.  That would
properly handle the return value and keep gcc, and everyone else, happy.

thanks,

greg k-h
--
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/