linux-kernel - Re: [PATCH v5 5/5] usb: gadget: udc-core: independent registration of gadgets and gadget drivers

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]

Message-ID: <CAB=otbRVMV8Ztu9FoL+5n+WjnbSJ91fM+CefnUeA1vpNiBDNYw@mail.gmail.com>
Date:	Sun, 28 Jun 2015 01:37:25 +0300
From:	Ruslan Bilovol <ruslan.bilovol@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"Balbi, Felipe" <balbi@...com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Krzysztof Opasiak <k.opasiak@...sung.com>,
	Peter Chen <peter.chen@...escale.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	Andrzej Pietrasiewicz <andrzej.p@...sung.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>
Subject: Re: [PATCH v5 5/5] usb: gadget: udc-core: independent registration of
 gadgets and gadget drivers

Hi Alan,

On Tue, Jun 23, 2015 at 5:08 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> On Tue, 23 Jun 2015, Ruslan Bilovol wrote:
>
>> Change behavior during registration of gadgets and
>> gadget drivers in udc-core. Instead of previous
>> approach when for successful probe of usb gadget driver
>> at least one usb gadget should be already registered
>> use another one where gadget drivers and gadgets
>> can be registered in udc-core independently.
>>
>> Independent registration of gadgets and gadget drivers
>> is useful for built-in into kernel gadget and gadget
>> driver case - because it's possible that gadget is
>> really probed only on late_init stage (due to deferred
>> probe) whereas gadget driver's probe is silently failed
>> on module_init stage due to no any UDC added.
>>
>> Also it is useful for modules case - now there is no
>> difference what module to insert first: gadget module
>> or gadget driver one.
>>
>> Tested-by: Maxime Ripard <maxime.ripard@...e-electrons.com>
>> Signed-off-by: Ruslan Bilovol <ruslan.bilovol@...il.com>
>
>> @@ -484,6 +507,16 @@ int usb_gadget_unregister_driver(struct usb_gadget_driver *driver)
>>                       break;
>>               }
>>
>> +     if (ret) {
>> +             struct usb_gadget_driver *tmp;
>> +
>> +             list_for_each_entry(tmp, &gadget_driver_pending_list, pending)
>> +                     if (tmp == driver) {
>> +                             list_del(&driver->pending);
>> +                             ret = 0;
>> +                             break;
>> +                     }
>> +     }
>
> Weren't you going to replace this loop with a simple list_del()?  IIRC,
> this is the third time I have asked you to make this change.

I understand the improvement that replacing this loop with a list_del()
may bring for us, but I disagree with doing it in this particular case.

The reason is simple. The usb_gadget_unregister_driver() funciton is
externally visible so we can get junk as input. Current implementation
checks passed pointer and only after that does list_del(), or
returns -EINVAL. Your variant will do list_del() unconditionally, that
may cause a kernel crash or unexpected behavior in case of junk
passed with *driver. The list_del_init() usage can't help here since
there is no way to check that list_head structure is initialized with correct
data or contains junk.

There is no noticeable performance loss with current implementation,just
because current use case is pretty simple: one gadget driver per one UDC,
and usually there is only one UDC per machine (or rare cases with few
UDCs), thus number of pending gadget drivers is relatively small.
We can return back to this discussion if someone needs to register
many gadget drivers, and want to improve performance, because
there are few existing places (not created by me) in this file that uses
same approach of walking through list of registered gadget drivers.

As a bottom line, choosing between stability and little performance
improvement, I prefer stability.

Best regards,
Ruslan
--
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/