similar to: [PATCH net V2] 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

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

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

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

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

Now that we have SCTP offload capabilities in the kernel, we can add them to virtio as well. First step is SCTP checksum. We need a new freature in virtio to negotiate this support since SCTP is excluded with the stardard checksum and requires a little bit extra. This series proposes VIRTIO_NET_F_SCTP_CSUM feature bit. As the "little bit extra", the kernel uses a new bit in the skb

Now that we have SCTP offload capabilities in the kernel, we can add them to virtio as well. First step is SCTP checksum. We need a new freature in virtio to negotiate this support since SCTP is excluded with the stardard checksum and requires a little bit extra. This series proposes VIRTIO_NET_F_SCTP_CSUM feature bit. As the "little bit extra", the kernel uses a new bit in the skb

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/macvlan.c | 5 +++-- >

On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > Since we now have support for software CRC32c offload, turn it on > for macvlan and macvtap devices so that guests can take advantage > of offload SCTP checksums to the host or host hardware. > > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- > drivers/net/macvlan.c | 5 +++-- >

On Mon, Apr 16, 2018 at 09:45:48AM -0400, Vlad Yasevich wrote: > On 04/11/2018 06:49 PM, Michael S. Tsirkin wrote: > > 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. > >>

Now that we have SCTP offload capabilities in the kernel, we can add them to virtio as well. First step is SCTP checksum. We need a new freature in virtio to negotiate this support since SCTP is excluded with the stardard checksum and requires a little bit extra. This series proposes VIRTIO_NET_F_SCTP_CSUM feature bit. As the "little bit extra", the kernel uses a new bit in the skb

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

On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: > On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > > On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > >> Since we now have support for software CRC32c offload, turn it on > >> for macvlan and macvtap devices so that guests can take advantage > >> of offload SCTP checksums to

On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote: > On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote: > > On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote: > >> Since we now have support for software CRC32c offload, turn it on > >> for macvlan and macvtap devices so that guests can take advantage > >> of offload SCTP checksums to

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

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