1. 16 7月, 2016 2 次提交
  2. 11 6月, 2016 1 次提交
  3. 09 5月, 2016 1 次提交
  4. 07 5月, 2016 1 次提交
    • M
      macvtap: add namespace support to the sysfs device class · 17af2bce
      Marc Angel 提交于
      When creating macvtaps that are expected to have the same ifindex
      in different network namespaces, only the first one will succeed.
      The others will fail with a sysfs_warn_dup warning due to them trying
      to create the following sysfs link (with 'NN' the ifindex of macvtapX):
      
      /sys/class/macvtap/tapNN -> /sys/devices/virtual/net/macvtapX/tapNN
      
      This is reproducible by running the following commands:
      
      ip netns add ns1
      ip netns add ns2
      ip link add veth0 type veth peer name veth1
      ip link set veth0 netns ns1
      ip link set veth1 netns ns2
      ip netns exec ns1 ip l add link veth0 macvtap0 type macvtap
      ip netns exec ns2 ip l add link veth1 macvtap1 type macvtap
      
      The last command will fail with "RTNETLINK answers: File exists" (along
      with the kernel warning) but retrying it will work because the ifindex
      was incremented.
      
      The 'net' device class is isolated between network namespaces so each
      one has its own hierarchy of net devices.
      This isn't the case for the 'macvtap' device class.
      The problem occurs half-way through the netdev registration, when
      `macvtap_device_event` is called-back to create the 'tapNN' macvtap
      class device under the 'macvtapX' net class device.
      
      This patch adds namespace support to the 'macvtap' device class so
      that /sys/class/macvtap is no longer shared between net namespaces.
      
      However, making the macvtap sysfs class namespace-aware has the side
      effect of changing /sys/devices/virtual/net/macvtapX/tapNN  into
      /sys/devices/virtual/net/macvtapX/macvtap/tapNN.
      
      This is due to Commit 24b1442d ("Driver-core: Always create class
      directories for classses that support namespaces") and the fact that
      class devices supporting namespaces are really not supposed to be placed
      directly under other class devices.
      
      To avoid breaking userland, a tapNN symlink pointing to macvtap/tapNN is
      created inside the macvtapX directory.
      Signed-off-by: NMarc Angel <marc@arista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      17af2bce
  5. 27 4月, 2016 1 次提交
  6. 12 3月, 2016 1 次提交
    • W
      macvtap: always pass ethernet header in linear · 8e2ad411
      Willem de Bruijn 提交于
      The stack expects link layer headers in the skb linear section.
      Macvtap can create skbs with llheader in frags in edge cases:
      when (IFF_VNET_HDR is off or vnet_hdr.hdr_len < ETH_HLEN) and
      prepad + len > PAGE_SIZE and vnet_hdr.flags has no or bad csum.
      
      Add checks to ensure linear is always at least ETH_HLEN.
      At this point, len is already ensured to be >= ETH_HLEN.
      
      For backwards compatiblity, rounds up short vnet_hdr.hdr_len.
      This differs from tap and packet, which return an error.
      
      Fixes b9fb9ee0 ("macvtap: add GSO/csum offload support")
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8e2ad411
  7. 16 12月, 2015 1 次提交
    • T
      net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK · a188222b
      Tom Herbert 提交于
      The name NETIF_F_ALL_CSUM is a misnomer. This does not correspond to the
      set of features for offloading all checksums. This is a mask of the
      checksum offload related features bits. It is incorrect to set both
      NETIF_F_HW_CSUM and NETIF_F_IP_CSUM or NETIF_F_IPV6 at the same time for
      features of a device.
      
      This patch:
        - Changes instances of NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK (where
          NETIF_F_ALL_CSUM is being used as a mask).
        - Changes bonding, sfc/efx, ipvlan, macvlan, vlan, and team drivers to
          use NEITF_F_HW_CSUM in features list instead of NETIF_F_ALL_CSUM.
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a188222b
  8. 02 12月, 2015 1 次提交
    • E
      net: rename SOCK_ASYNC_NOSPACE and SOCK_ASYNC_WAITDATA · 9cd3e072
      Eric Dumazet 提交于
      This patch is a cleanup to make following patch easier to
      review.
      
      Goal is to move SOCK_ASYNC_NOSPACE and SOCK_ASYNC_WAITDATA
      from (struct socket)->flags to a (struct socket_wq)->flags
      to benefit from RCU protection in sock_wake_async()
      
      To ease backports, we rename both constants.
      
      Two new helpers, sk_set_bit(int nr, struct sock *sk)
      and sk_clear_bit(int net, struct sock *sk) are added so that
      following patch can change their implementation.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9cd3e072
  9. 10 11月, 2015 1 次提交
    • V
      macvtap: Resolve possible __might_sleep warning in macvtap_do_read() · a499a2e9
      Vlad Yasevich 提交于
      macvtap_do_read code calls macvtap_put_user while it might be set up
      to wait for the user.  This results in the following warning:
      
      Jun 23 16:25:26 galen kernel: ------------[ cut here ]------------
      Jun 23 16:25:26 galen kernel: WARNING: CPU: 0 PID: 30433 at kernel/sched/core.c:
      7286 __might_sleep+0x7f/0x90()
      Jun 23 16:25:26 galen kernel: do not call blocking ops when !TASK_RUNNING; state
      =1 set at [<ffffffff810f1c1f>] prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: CPU: 0 PID: 30433 Comm: cat Not tainted 4.1.0-rc6+
       #11
      Jun 23 16:25:26 galen kernel: Call Trace:
      Jun 23 16:25:26 galen kernel: [<ffffffff817f76ba>] dump_stack+0x4c/0x65
      Jun 23 16:25:26 galen kernel: [<ffffffff810a07ca>] warn_slowpath_common+0x8a/0xc
      0
      Jun 23 16:25:26 galen kernel: [<ffffffff810a0846>] warn_slowpath_fmt+0x46/0x50
      Jun 23 16:25:26 galen kernel: [<ffffffff810f1c1f>] ?  prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff810f1c1f>] ?  prepare_to_wait+0x2f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff810cdc1f>] __might_sleep+0x7f/0x90
      Jun 23 16:25:26 galen kernel: [<ffffffff811f8e15>] might_fault+0x55/0xb0
      Jun 23 16:25:26 galen kernel: [<ffffffff810fab9d>] ?  trace_hardirqs_on_caller+0x fd/0x1c0
      Jun 23 16:25:26 galen kernel: [<ffffffff813f639c>] copy_to_iter+0x7c/0x360
      Jun 23 16:25:26 galen kernel: [<ffffffffa052da86>] macvtap_do_read+0x256/0x3d0 [macvtap]
      Jun 23 16:25:26 galen kernel: [<ffffffff810f20e0>] ?  prepare_to_wait_event+0x110/0x110
      Jun 23 16:25:26 galen kernel: [<ffffffffa052dcab>] macvtap_read_iter+0x2b/0x50 [macvtap]
      Jun 23 16:25:26 galen kernel: [<ffffffff81247f2e>] __vfs_read+0xae/0xe0
      Jun 23 16:25:26 galen kernel: [<ffffffff81248526>] vfs_read+0x86/0x140
      Jun 23 16:25:26 galen kernel: [<ffffffff812493b9>] SyS_read+0x49/0xb0
      Jun 23 16:25:26 galen kernel: [<ffffffff8180182e>] system_call_fastpath+0x12/0x76
      Jun 23 16:25:26 galen kernel: ---[ end trace 22e33f67e70c0c2a ]---
      
      Make sure thet we call finish_wait() if we have the skb to process
      before trying to actually process it.
      Signed-off-by: NVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a499a2e9
  10. 23 10月, 2015 1 次提交
  11. 21 9月, 2015 1 次提交
  12. 28 7月, 2015 1 次提交
  13. 09 7月, 2015 1 次提交
    • J
      macvtap: Destroy minor_idr on module_exit · d5de1987
      Johannes Thumshirn 提交于
      Destroy minor_idr on module_exit, reclaiming the allocated memory.
      
      This was detected by the following semantic patch (written by Luis Rodriguez
      <mcgrof@suse.com>)
      <SmPL>
      @ defines_module_init @
      declarer name module_init, module_exit;
      declarer name DEFINE_IDR;
      identifier init;
      @@
      
      module_init(init);
      
      @ defines_module_exit @
      identifier exit;
      @@
      
      module_exit(exit);
      
      @ declares_idr depends on defines_module_init && defines_module_exit @
      identifier idr;
      @@
      
      DEFINE_IDR(idr);
      
      @ on_exit_calls_destroy depends on declares_idr && defines_module_exit @
      identifier declares_idr.idr, defines_module_exit.exit;
      @@
      
      exit(void)
      {
       ...
       idr_destroy(&idr);
       ...
      }
      
      @ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @
      identifier declares_idr.idr, defines_module_exit.exit;
      @@
      
      exit(void)
      {
       ...
       +idr_destroy(&idr);
      }
      </SmPL>
      Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5de1987
  14. 23 6月, 2015 1 次提交
    • P
      macvtap: Increase limit of macvtap queues · dfe816c5
      Pankaj Gupta 提交于
      Macvtap should be compatible with tuntap for
      maximum number of queues.
      
      commit 'baf71c5c (tuntap:
      Increase the number of queues in tun.)' removes
      the limitations and increases number of queues in tuntap.
      Now, Its safe to increase number of queues in Macvtap as well.
      
      This patch also modifies 'macvtap_del_queues' function
      to avoid extra memory allocation in stack.
      
      Changes from v1->v2 :
      Michael S. Tsirkin, Jason Wang  :
                        Better way to use linked list to
      avoid use of extra memory in stack.
      Sergei Shtylyov : Specify dependent commit's summary.
      Signed-off-by: NPankaj Gupta <pagupta@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dfe816c5
  15. 01 6月, 2015 3 次提交
  16. 14 5月, 2015 1 次提交
  17. 13 5月, 2015 1 次提交
  18. 11 5月, 2015 1 次提交
  19. 18 4月, 2015 1 次提交
  20. 12 4月, 2015 1 次提交
  21. 03 3月, 2015 1 次提交
  22. 01 3月, 2015 1 次提交
  23. 04 2月, 2015 2 次提交
  24. 14 1月, 2015 1 次提交
  25. 17 12月, 2014 2 次提交
  26. 10 12月, 2014 1 次提交
    • A
      put iov_iter into msghdr · c0371da6
      Al Viro 提交于
      Note that the code _using_ ->msg_iter at that point will be very
      unhappy with anything other than unshifted iovec-backed iov_iter.
      We still need to convert users to proper primitives.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      c0371da6
  27. 09 12月, 2014 1 次提交
  28. 06 12月, 2014 1 次提交
  29. 24 11月, 2014 2 次提交
  30. 22 11月, 2014 1 次提交
  31. 08 11月, 2014 1 次提交
  32. 04 11月, 2014 1 次提交
  33. 31 10月, 2014 2 次提交
    • B
      drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets · 5188cd44
      Ben Hutchings 提交于
      UFO is now disabled on all drivers that work with virtio net headers,
      but userland may try to send UFO/IPv6 packets anyway.  Instead of
      sending with ID=0, we should select identifiers on their behalf (as we
      used to).
      Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
      Fixes: 916e4cf4 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5188cd44
    • B
      drivers/net: Disable UFO through virtio · 3d0ad094
      Ben Hutchings 提交于
      IPv6 does not allow fragmentation by routers, so there is no
      fragmentation ID in the fixed header.  UFO for IPv6 requires the ID to
      be passed separately, but there is no provision for this in the virtio
      net protocol.
      
      Until recently our software implementation of UFO/IPv6 generated a new
      ID, but this was a bug.  Now we will use ID=0 for any UFO/IPv6 packet
      passed through a tap, which is even worse.
      
      Unfortunately there is no distinction between UFO/IPv4 and v6
      features, so disable UFO on taps and virtio_net completely until we
      have a proper solution.
      
      We cannot depend on VM managers respecting the tap feature flags, so
      keep accepting UFO packets but log a warning the first time we do
      this.
      Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
      Fixes: 916e4cf4 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d0ad094