All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Jiri Slaby <jslaby@suse.cz>
Cc: Jiri Kosina <jkosina@suse.cz>,
	linux-kernel@vger.kernel.org,
	USB list <linux-usb@vger.kernel.org>
Subject: Re: [PATCH] usb-hid-core: Set intfdata to NULL if probe fails
Date: Tue, 22 May 2012 11:33:00 +0200	[thread overview]
Message-ID: <4FBB5D4C.9090804@redhat.com> (raw)
In-Reply-To: <4FBB4E51.6020607@suse.cz>

Hi,

On 05/22/2012 10:29 AM, Jiri Slaby wrote:
> On 05/22/2012 10:09 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 05/22/2012 09:56 AM, Jiri Slaby wrote:
>>> On 05/21/2012 09:39 PM, Hans de Goede wrote:
>>>> other drivers which rely on frameworks which only call dev_set_drvdata
>>>> on the interface's device if no drvdata has been set
>>>
>>> This looks very broken as it relies on an undocumented behavior.
>>
>> I don't see how expecting intfdata to be NULL when an USB driver's
>> probe function gets called is broken, esp. since most
>> USB drivers will unconditionally set intfdata to something from
>> their probe functions, so it seems reasonable to assume that it is
>> not pointing to anything before probe gets called.
>
> As you can see, it is not.

Notice I used the word "reasoanble" I still believe it is reasonable
to expect intfdata to be NULL. intfdata is just an alias for dev_drvdata,
and if no driver is bound to a device what should its drvdata be?

So we have:
1) A device which does not have a driver bound
2) A potential drivers probe method being called (which will only
    happen if 1. is true)
3) That probe method expecting drvdata to be NULL since no driver is
    bound

Surprise surprise (not). If no driver is bound what else can drvdata
be but NULL, anything else would be a reminisce of a previous driver,
and thus very likely a dangling pointer.

>> it should
>> be NULL when their probe gets called.
>
> No, this is not documented anywhere as far as I can see. And many
> drivers just don't do that. The same for PCI and likely other buses
> (like HID).

Well on driver unbind the USB core explictly sets intfdata to NULL,
which to me clearly signals intent that intfdata should be NULL when
no driver is bound.

The usb code does not do clear intfdata on probe fail, I don't know why,
likely because it expects a failed probe to not set it in the first
place! But it probably is a very good idea to make the USB core set
intfdata to NULL after a failed probe to ensure that it is NULL
when no driver is bound, independent of driver behavior.

>> I cannot believe we are
>> even having this discussion, are you really trying to argue
>> that leaving intfdata as a dangling pointer, rather then setting
>> it to NULL (*) is better???
>
> No, the patch looks correct. But you are expecting something which is
> not still guaranteed.

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.

Regards,

Hans

  reply	other threads:[~2012-05-22  9:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21 19:39 [PATCH] usb-hid-core: Set intfdata to NULL if probe fails Hans de Goede
2012-05-22  7:56 ` Jiri Slaby
2012-05-22  8:09   ` Hans de Goede
2012-05-22  8:29     ` Jiri Slaby
2012-05-22  9:33       ` Hans de Goede [this message]
2012-05-22 22:00         ` Jiri Kosina
2012-05-22 22:08           ` Hans de Goede
2012-05-22 22:10           ` Greg KH
2012-05-22 22:14             ` Jiri Kosina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FBB5D4C.9090804@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.