On 12/25/2013 10:56 PM, Michael S. Tsirkin wrote:
> Eric Dumazet noticed that if we encounter an error
> when processing a mergeable buffer, we don't
> dequeue all of the buffers from this packet,
> the result is almost sure to be loss of networking.
>
> Jason Wang noticed that we also leak a page
Acked-by: Michael Dalton
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, Dec 25, 2013 at 10:33:37AM -0800, Michael Dalton wrote:
> Hi Michael, quick question below:
>
> On Wed, Dec 25, 2013 at 6:56 AM, Michael S. Tsirkin wrote:
> > if (i >= MAX_SKB_FRAGS) {
> > pr_debug("%s: packet too long\n", skb->dev->name);
> >
Hi Michael, quick question below:
On Wed, Dec 25, 2013 at 6:56 AM, Michael S. Tsirkin wrote:
> if (i >= MAX_SKB_FRAGS) {
> pr_debug("%s: packet too long\n", skb->dev->name);
> skb->dev->stats.rx_length_errors++;
> -
Eric Dumazet noticed that if we encounter an error
when processing a mergeable buffer, we don't
dequeue all of the buffers from this packet,
the result is almost sure to be loss of networking.
Jason Wang noticed that we also leak a page and that we don't decrement
the rq buf count, so we won't rep
5 matches
Mail list logo