From: Felipe Balbi <balbi@kernel.org>
To: Andrey Konovalov <andreyknvl@google.com>
Cc: USB list <linux-usb@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jonathan Corbet <corbet@lwn.net>,
Alan Stern <stern@rowland.harvard.edu>,
Dmitry Vyukov <dvyukov@google.com>,
Alexander Potapenko <glider@google.com>,
Marco Elver <elver@google.com>
Subject: Re: [PATCH v5 1/1] usb: gadget: add raw-gadget interface
Date: Fri, 31 Jan 2020 17:22:09 +0200 [thread overview]
Message-ID: <87a7637ise.fsf@kernel.org> (raw)
In-Reply-To: <CAAeHK+wwmis4z9ifPAnkM36AnfG2oESSLAkKvDkuAa0QUM2wRg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2979 bytes --]
Hi,
Andrey Konovalov <andreyknvl@google.com> writes:
>> > diff --git a/drivers/usb/gadget/legacy/raw_gadget.c b/drivers/usb/gadget/legacy/raw_gadget.c
>> > new file mode 100644
>> > index 000000000000..51796af48069
>> > --- /dev/null
>> > +++ b/drivers/usb/gadget/legacy/raw_gadget.c
>> > @@ -0,0 +1,1068 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>>
>> V2 only
>
> Like this: SPDX-License-Identifier: GPL-2.0 only ?
Right, you need to choose if you want 2.0-only or 2.0-or-later and make
sure spdx and module_license() agree.
https://spdx.org/licenses/GPL-2.0-only.html
What you had before, implies GPL-2.0-only...
>> > +MODULE_LICENSE("GPL");
but this is GPL 2+
/me goes look
Actually Thomas Gleixner changed the meaning of MODULE_LICENSE("GPL"),
so I don't really know how this should look today.
>> > +static int raw_event_queue_add(struct raw_event_queue *queue,
>> > + enum usb_raw_event_type type, size_t length, const void *data)
>> > +{
>> > + unsigned long flags;
>> > + struct usb_raw_event *event;
>> > +
>> > + spin_lock_irqsave(&queue->lock, flags);
>> > + if (WARN_ON(queue->size >= RAW_EVENT_QUEUE_SIZE)) {
>> > + spin_unlock_irqrestore(&queue->lock, flags);
>> > + return -ENOMEM;
>> > + }
>> > + event = kmalloc(sizeof(*event) + length, GFP_ATOMIC);
>>
>> I would very much prefer dropping GFP_ATOMIC here. Must you have this
>> allocation under a spinlock?
>
> The issue here is not the spinlock, but that this might be called in
> interrupt context. The number of atomic allocations here is restricted
> by 128, and we can reduce the limit even further (until some point in
> the future when and if we'll report more different events). Another
> option would be to preallocate the required number of objects
> (although we don't know the required size in advance, so we'll waste
> some memory) and use those. What would you prefer?
I think you shouldn't do either :-) Here's what I think you should do:
1. support O_NONBLOCK. This just means conditionally removing your
wait_for_completion_interruptible().
2. Every time user calls write(), you usb_ep_alloc(), allocate a buffer
with the write size, copy buffer to kernel space,
usb_ep_queue(). When complete() callback is called, then you free the
request. This would allow us to amortize the cost of copy_from_user()
with several requests being queued to USB controller.
3. Have a pre-allocated list of requests (128?) for read(). Enqueue them
all during set_alt(). When user calls read() you will:
a) check if there are completed requests to be copied over to
userspace. Recycle the request.
b) if there are no completed requests, then it depends on O_NONBLOCK
i) If O_NONBLOCK, return -EWOULDBLOCK
ii) otherwise, wait_for_completion
I think this can all be done without any GFP_ATOMIC allocations.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2020-01-31 15:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 13:24 [PATCH v5 0/1] usb: gadget: add raw-gadget interface Andrey Konovalov
2020-01-14 13:24 ` [PATCH v5 1/1] " Andrey Konovalov
2020-01-14 14:00 ` Greg Kroah-Hartman
2020-01-22 14:37 ` Andrey Konovalov
2020-01-22 14:50 ` Greg Kroah-Hartman
2020-01-27 12:27 ` Andrey Konovalov
2020-01-31 13:42 ` Felipe Balbi
2020-01-31 14:43 ` Andrey Konovalov
2020-01-31 15:22 ` Felipe Balbi [this message]
2020-02-03 18:08 ` Andrey Konovalov
2020-02-05 16:42 ` Felipe Balbi
2020-02-05 17:25 ` Andrey Konovalov
2020-02-05 21:18 ` Greg Kroah-Hartman
2020-02-06 6:19 ` Felipe Balbi
2020-02-06 19:21 ` Andrey Konovalov
2020-02-05 21:18 ` Greg Kroah-Hartman
2020-02-06 6:14 ` Felipe Balbi
2020-01-31 21:42 ` Greg Kroah-Hartman
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=87a7637ise.fsf@kernel.org \
--to=balbi@kernel.org \
--cc=andreyknvl@google.com \
--cc=corbet@lwn.net \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).