similar to: [PATCH net] virtio-net: drop NETIF_F_FRAGLIST

virtio declares support for NETIF_F_FRAGLIST, but assumes that there are at most MAX_SKB_FRAGS + 2 fragments which isn't always true with a fraglist. A longer fraglist in the skb will make the call to skb_to_sgvec overflow the sg array, leading to memory corruption. Drop NETIF_F_FRAGLIST so we only get what we can handle. Cc: Michael S. Tsirkin <mst at redhat.com> Signed-off-by: Jason

virtio declares support for NETIF_F_FRAGLIST, but assumes that there are at most MAX_SKB_FRAGS + 2 fragments which isn't always true with a fraglist. A longer fraglist in the skb will make the call to skb_to_sgvec overflow the sg array, leading to memory corruption. Drop NETIF_F_FRAGLIST so we only get what we can handle. Cc: Michael S. Tsirkin <mst at redhat.com> Signed-off-by: Jason

Hello. On 8/4/2015 12:55 PM, Jason Wang wrote: > virtio declares support for NETIF_F_FRAGLIST, but assumes > that there are at most MAX_SKB_FRAGS + 2 fragments which isn't > always true with a fraglist. > A longer fraglist in the skb will make the call to skb_to_sgvec overflow > the sg array, leading to memory corruption. > Drop NETIF_F_FRAGLIST so we only get what we can

On Wed, Aug 05, 2015 at 10:34:04AM +0800, Jason Wang wrote: > virtio declares support for NETIF_F_FRAGLIST, but assumes > that there are at most MAX_SKB_FRAGS + 2 fragments which isn't > always true with a fraglist. > > A longer fraglist in the skb will make the call to skb_to_sgvec overflow > the sg array, leading to memory corruption. > > Drop NETIF_F_FRAGLIST so we

When vlan device is configured on top of the brige, it does not support any offload capabilities because the bridge device does not initiliaze vlan_fatures. Set vlan_fatures to be equivalent to hw_fatures. Signed-off-by: Vlad Yasevich <vyasevic at redhat.com> --- net/bridge/br_device.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/net/bridge/br_device.c

UFO support in the kernel applies to both IPv4 and IPv6 protocols with the same device feature. However some devices may not be able to support one of the offloads. For this we split the UFO offload feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part and this series introduces NETIF_F_UFO6. As a result of this work, we can now re-enable NETIF_F_UFO on virtio_net devices and restore

UFO support in the kernel applies to both IPv4 and IPv6 protocols with the same device feature. However some devices may not be able to support one of the offloads. For this we split the UFO offload feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part and this series introduces NETIF_F_UFO6. As a result of this work, we can now re-enable NETIF_F_UFO on virtio_net devices and restore

The virtio net protocol supports UFO but does not provide for passing a fragment ID for fragmentation of IPv6 packets. We used to generate a fragment ID wherever such a packet was fragmented, but currently we always use ID=0! v2: Add blank lines after declarations Ben. Ben Hutchings (2): drivers/net: Disable UFO through virtio drivers/net,ipv6: Select IPv6 fragment idents for virtio UFO

The virtio net protocol supports UFO but does not provide for passing a fragment ID for fragmentation of IPv6 packets. We used to generate a fragment ID wherever such a packet was fragmented, but currently we always use ID=0! v2: Add blank lines after declarations Ben. Ben Hutchings (2): drivers/net: Disable UFO through virtio drivers/net,ipv6: Select IPv6 fragment idents for virtio UFO

commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 Author: Ben Hutchings <ben at decadent.org.uk> Date: Thu Oct 30 18:27:12 2014 +0000 drivers/net: Disable UFO through virtio Turned off UFO support to virtio-net based devices due to issues with IPv6 fragment id generation for UFO packets. The issue was that IPv6 UFO/GSO implementation expects the fragment id to be supplied in

commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 Author: Ben Hutchings <ben at decadent.org.uk> Date: Thu Oct 30 18:27:12 2014 +0000 drivers/net: Disable UFO through virtio Turned off UFO support to virtio-net based devices due to issues with IPv6 fragment id generation for UFO packets. The issue was that IPv6 UFO/GSO implementation expects the fragment id to be supplied in

The virtio net protocol supports UFO but does not provide for passing a fragment ID for fragmentation of IPv6 packets. We used to generate a fragment ID wherever such a packet was fragmented, but currently we always use ID=0! Ben. Ben Hutchings (2): drivers/net: Disable UFO through virtio drivers/net,ipv6: Select IPv6 fragment idents for virtio UFO packets drivers/net/macvtap.c | 16

The virtio net protocol supports UFO but does not provide for passing a fragment ID for fragmentation of IPv6 packets. We used to generate a fragment ID wherever such a packet was fragmented, but currently we always use ID=0! Ben. Ben Hutchings (2): drivers/net: Disable UFO through virtio drivers/net,ipv6: Select IPv6 fragment idents for virtio UFO packets drivers/net/macvtap.c | 16

commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 Author: Ben Hutchings <ben at decadent.org.uk> Date: Thu Oct 30 18:27:12 2014 +0000 drivers/net: Disable UFO through virtio Turned off UFO support to virtio-net based devices due to issues with IPv6 fragment id generation for UFO packets. The issue was that IPv6 UFO/GSO implementation expects the fragment id to be supplied in

commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 Author: Ben Hutchings <ben at decadent.org.uk> Date: Thu Oct 30 18:27:12 2014 +0000 drivers/net: Disable UFO through virtio Turned off UFO support to virtio-net based devices due to issues with IPv6 fragment id generation for UFO packets. The issue was that IPv6 UFO/GSO implementation expects the fragment id to be supplied in

commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 Author: Ben Hutchings <ben at decadent.org.uk> Date: Thu Oct 30 18:27:12 2014 +0000 drivers/net: Disable UFO through virtio Turned off UFO support to virtio-net based devices due to issues with IPv6 fragment id generation for UFO packets. The issue was that IPv6 UFO/GSO implementation expects the fragment id to be supplied in

commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4 Author: Ben Hutchings <ben at decadent.org.uk> Date: Thu Oct 30 18:27:12 2014 +0000 drivers/net: Disable UFO through virtio Turned off UFO support to virtio-net based devices due to issues with IPv6 fragment id generation for UFO packets. The issue was that IPv6 UFO/GSO implementation expects the fragment id to be supplied in

On Mon, Apr 02, 2018 at 09:40:02AM -0400, Vladislav Yasevich wrote: > To support SCTP checksum offloading, we need to add a new feature > to virtio_net, so we can negotiate support between the hypervisor > and the guest. > > The signalling to the guest that an alternate checksum needs to > be used is done via a new flag in the virtio_net_hdr. If the > flag is set, the host

On Mon, Apr 02, 2018 at 09:40:02AM -0400, Vladislav Yasevich wrote: > To support SCTP checksum offloading, we need to add a new feature > to virtio_net, so we can negotiate support between the hypervisor > and the guest. > > The signalling to the guest that an alternate checksum needs to > be used is done via a new flag in the virtio_net_hdr. If the > flag is set, the host

Signed-off-by: Micha? Miros?aw <mirq-linux at rere.qmqm.pl> --- drivers/net/virtio_net.c | 46 +++++++++++++++++++--------------------------- 1 files changed, 19 insertions(+), 27 deletions(-) This is an example conversion to hw_features when constraints are constant and can be detected at init time. Build tested only. diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c