linux-kernel - Re: [PATCH] usb-hid-core: Set intfdata to NULL if probe fails

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:	Tue, 22 May 2012 15:10:17 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Hans de Goede <hdegoede@...hat.com>, Jiri Slaby <jslaby@...e.cz>,
	linux-kernel@...r.kernel.org, USB list <linux-usb@...r.kernel.org>
Subject: Re: [PATCH] usb-hid-core: Set intfdata to NULL if probe fails

On Wed, May 23, 2012 at 12:00:37AM +0200, Jiri Kosina wrote:
> On Tue, 22 May 2012, Hans de Goede wrote:
> 
> > Well then lets work towards making it guaranteed, since I still believe
> > the following holds true:
> > 1) drvdata is for a driver to store a pointer to driver specific data
> > 2) If no driver is bound, there is no driver specific data associated with
> >    the device
> > 3) Thus logically drvdata should be NULL if no driver is bound.
> > 
> > I'll do a patch for the USB-core to ensure that intfdata gets set to NULL
> > on probe failure.
> 
> Hans,
> 
> I believe this is a good thing per se, but shouldn't this rather be done 
> in driver core, to guarantee that this hold across all buses?

Maybe, but that would require that the driver core set the field to NULL
after every probe call that fails?  Is that really necessary to fix up
bugs in different bus subsystems that forget to clean up properly?

I'm not saying it's a bad thing to change it there, it just seems a bit
heavy-handed for a very rare event.

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/