netdev - Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active

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: <CACVXFVMW2Dosr0FAKCvxgUFQKmwbduiC+HqmzS1tsvAHu=G8Kg@mail.gmail.com>
Date:	Thu, 11 Apr 2013 16:37:53 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Bjørn Mork <bjorn@...k.no>
Cc:	Oliver Neukum <oliver@...kum.org>, Dan Williams <dcbw@...hat.com>,
	Elina Pasheva <epasheva@...rrawireless.com>,
	Network Development <netdev@...r.kernel.org>,
	linux-usb <linux-usb@...r.kernel.org>,
	Rory Filer <rfiler@...rrawireless.com>,
	Phil Sutter <phil@....cc>
Subject: Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active

On Thu, Apr 11, 2013 at 4:06 PM, Bjørn Mork <bjorn@...k.no> wrote:
> Oliver Neukum <oliver@...kum.org> writes:
>
> My immediate thought was that someone also might want to use this new
> API from atomic context, e.g. calling it directly from an URB callback.

I am wondering it is a valid use case, and if there is one URB submitted,
the interrupt URB for status has been submitted already, hasn't it?

> But that is of course not possible taking a mutex.  Could the lock
> preventing interrupt_count maybe be a spinlock instead?  Or am I on the
> completely wrong track here?

Also it is a bit odd that the 'start' API is allowed in atomic context, but
the 'stop' API isn't allowed, and it is very easy to cause unbalanced counter.

>
> In any case, I don't see the point unnecessarily limiting the API by
> dropping the memflags.  What possible problem would that solve?

If you think 'start' API should be called in atomic context, the memflags
should be always 'GFP_ATOMIC'. I let Oliver explain why GFP_NOIO
is needed in other cases.

Thanks
-- 
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html