diff options
author | Kostya B <bkostya@hotmail.com> | 2008-04-29 22:36:30 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2008-04-29 22:36:30 -0700 |
commit | be9164e769d57aa10b2bbe15d103edc041b9e7de (patch) | |
tree | 35f8c540da31cb8cafa1e6948ae682fd3c8d6bfa /arch/arm/mach-ixp4xx | |
parent | 3a8209d19dd791aaac3668be2fa51a9b42113efd (diff) |
[IPv4] UFO: prevent generation of chained skb destined to UFO device
Problem: ip_append_data() could wrongly generate a chained skb for
devices which support UFO. When sk_write_queue is not empty
(e.g. MSG_MORE), __instead__ of appending data into the next nr_frag
of the queued skb, a new chained skb is created.
I would normally assume UFO device should get data in nr_frags and not
in frag_list. Later the udp4_hwcsum_outgoing() resets csum to NONE
and skb_gso_segment() has oops.
Proposal:
1. Even length is less than mtu, employ ip_ufo_append_data()
and append data to the __existed__ skb in the sk_write_queue.
2. ip_ufo_append_data() is fixed due to a wrong manipulation of
peek-ing and later enqueue-ing of the same skb. Now, enqueuing is
always performed, because on error the further
ip_flush_pending_frames() would release the queued skb.
Signed-off-by: Kostya B <bkostya@hotmail.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'arch/arm/mach-ixp4xx')
0 files changed, 0 insertions, 0 deletions