On Sat, 2007-09-22 at 13:53 -0700, David Brownell wrote:
> > Sigh. I need a real deep look inside that code to understand, why
> > tx_reqs is not a requestlist but a freelist. Very intuitive naming :)
>
> It *is* a list of requests: free ones -- the only kind this level of
> driver is allowed to
> Sigh. I need a real deep look inside that code to understand, why
> tx_reqs is not a requestlist but a freelist. Very intuitive naming :)
It *is* a list of requests: free ones -- the only kind this level of
driver is allowed to remember! ;)
Yeah, I had to go back and read the driver again bef
On Sat, 2007-09-22 at 13:14 -0700, David Brownell wrote:
> How's this? Note that the queue should already have been stopped,
> so I removed what should be an extra call (as well as fixing the
> comments).
Yeah, stop queue should be not necessary.
> - Dave
>
>
> From: Thomas Gleixner <
How's this? Note that the queue should already have been stopped,
so I removed what should be an extra call (as well as fixing the
comments).
- Dave
From: Thomas Gleixner <[EMAIL PROTECTED]>
This patch fixes a longstanding race in the Ethernet gadget driver,
which can cause an oops on
On Sat, 2007-09-22 at 12:18 -0700, David Brownell wrote:
> I think you misread my comment. Those requests are **NOT** pending!!
> So this update has a *MORE* incorrect description of the issue.
>
> That's just the freelist ... it's a fairly conventional model whereby
> there's a pool of "free"
yers in the network stack started a transmission on
an active (pre-disconnect) TX queue.
That problem is *NOT* related to any pending requests at all!!
NAK...
> From [EMAIL PROTECTED] Sat Sep 22 10:51:00 2007
> Subject: [PATCH] usb-gadget-ether: Prevent oops caused by error interrupt
>
From: Benedikt Spranger <[EMAIL PROTECTED]>
eth_start_xmit() can race against a disconnect interrupt in the gadget
device driver, which nukes all pending request. Right now we access the
pending request list unconditionally and dereference the request list
head itself in such a case, which result
On Thursday 20 September 2007, Thomas Gleixner wrote:
> From: Benedikt Spranger <[EMAIL PROTECTED]>
>
> An USB error interrupt (e.g. disconnect) nukes the pending requests for
> an ethernet gadget device asynchronously. This can race against
> eth_start_xmit(), where we end up dereferencing the li
From: Benedikt Spranger <[EMAIL PROTECTED]>
An USB error interrupt (e.g. disconnect) nukes the pending requests for
an ethernet gadget device asynchronously. This can race against
eth_start_xmit(), where we end up dereferencing the list head itself.
The nuke code is serialized against eth_start_x
9 matches
Mail list logo
