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 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.