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/
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/
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++;
> -
Thanks Andrey, great catch. I believe this issue occurs in one more
place, when packets are dropped if they are too short. I will send
out a patch momentarily to fix that additional case.
Best,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
Hi,
After further reflection I think we're looking at two related issues:
(a) a memory leak that Jason has identified that occurs when a memory
allocation fails in receive_mergeable. Jasons commit solves this issue.
(b) virtio-net does not dequeue all buffers for a packet in the
case that an error
Great catch Jason. I agree this now raises the larger issue of how to
handle a memory alloc failure in the middle of receive. As Eric mentioned,
we can drop the packet and free the remaining (num_buf) frags.
Michael, perhaps I'm missing something, but why would you prefer
pre-allocating buffers in
6 matches
Mail list logo
