On 25-04-2014 18:49, Eric Dumazet wrote:
On Fri, 2014-04-25 at 18:01 +0200, Svenning Sørensen wrote:
You are right, of course, there are more effective ways to catch buggy
drivers.
But they will probably also be much more expensive.
This one is very cheap, being in a relatively cold path, espe
On Fri, 2014-04-25 at 18:01 +0200, Svenning Sørensen wrote:
> You are right, of course, there are more effective ways to catch buggy
> drivers.
> But they will probably also be much more expensive.
> This one is very cheap, being in a relatively cold path, especially
> compared to the memcpy in
On 25-04-2014 17:43, Eric Dumazet wrote:
If you want a debugging patch, this should happen way before TCP stack
or even IP stack.
Say you want to use this buggy driver on a router, this code path will
never bit hit.
You are right, of course, there are more effective ways to catch buggy
drive
On Fri, 2014-04-25 at 17:02 +0200, Svenning Sørensen wrote:
> This patch adds a guard against coalescing packets received by buggy network
> drivers that don't initialize skb->tail properly.
>
> Coalescing such packets will corrupt data in a way that makes it hard to
> track down the real cause of
This patch adds a guard against coalescing packets received by buggy network
drivers that don't initialize skb->tail properly.
Coalescing such packets will corrupt data in a way that makes it hard to
track down the real cause of the problem. Observed symptoms are a flood of
WARNs by tcp_recvmsg a
5 matches
Mail list logo
