All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

  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.