From: Felipe Balbi <balbi@ti.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Ruslan Bilovol <ruslan.bilovol@gmail.com>,
"Balbi, Felipe" <balbi@ti.com>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Krzysztof Opasiak <k.opasiak@samsung.com>,
Peter Chen <peter.chen@freescale.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
Maxime Ripard <maxime.ripard@free-electrons.com>
Subject: Re: [PATCH v5 5/5] usb: gadget: udc-core: independent registration of gadgets and gadget drivers
Date: Mon, 6 Jul 2015 12:38:29 -0500 [thread overview]
Message-ID: <20150706173829.GA20779@saruman.tx.rr.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1506271938120.32458-100000@netrider.rowland.org>
[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]
On Sat, Jun 27, 2015 at 07:47:28PM -0400, Alan Stern wrote:
> On Sun, 28 Jun 2015, Ruslan Bilovol wrote:
>
> > > 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.
>
> That's right.
>
> > 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.
>
> It's not really a question of code size or performance. As you say,
> the difference in each is minimal.
>
> It _is_ a question of style. Adding unnecessary code to check for
> something that shouldn't need to be checked looks bad. Other kernel
> developers reading that code will notice it and wonder why it's there.
> That's the argument for getting rid of the loop.
yeah, if someone gives us junk as input, they deserve to oops.
list_del() is enough.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-07-06 17:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-22 22:01 [PATCH v5 0/5] usb/gadget: independent registration of gadgets and gadget drivers Ruslan Bilovol
2015-06-22 22:01 ` [PATCH v5 1/5] usb: gadget: bind UDC by name passed via usb_gadget_driver structure Ruslan Bilovol
2015-06-22 22:01 ` [PATCH v5 2/5] usb: gadget: configfs: pass UDC name via usb_gadget_driver struct Ruslan Bilovol
2015-06-23 6:54 ` Krzysztof Opasiak
2015-06-27 14:33 ` Ruslan Bilovol
2015-06-22 22:01 ` [PATCH v5 3/5] usb: gadget: udc-core: remove unused usb_udc_attach_driver() Ruslan Bilovol
2015-06-22 22:01 ` [PATCH v5 4/5] usb: gadget: legacy: don't use __init/__exit attributes for bind/unbind path Ruslan Bilovol
2015-06-22 22:01 ` [PATCH v5 5/5] usb: gadget: udc-core: independent registration of gadgets and gadget drivers Ruslan Bilovol
2015-06-23 14:08 ` Alan Stern
2015-06-27 22:37 ` Ruslan Bilovol
2015-06-27 23:47 ` Alan Stern
2015-07-06 17:38 ` Felipe Balbi [this message]
2015-10-19 8:11 ` [PATCH v5 0/5] usb/gadget: " Maxime Ripard
2015-11-02 16:44 ` Ruslan Bilovol
2015-11-09 0:07 ` Maxime Ripard
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=20150706173829.GA20779@saruman.tx.rr.com \
--to=balbi@ti.com \
--cc=andrzej.p@samsung.com \
--cc=gregkh@linuxfoundation.org \
--cc=k.opasiak@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=peter.chen@freescale.com \
--cc=ruslan.bilovol@gmail.com \
--cc=stern@rowland.harvard.edu \
/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.