1. 12 2月, 2017 6 次提交
  2. 07 2月, 2017 1 次提交
  3. 21 1月, 2017 1 次提交
  4. 06 12月, 2016 1 次提交
    • A
      [iov_iter] new primitives - copy_from_iter_full() and friends · cbbd26b8
      Al Viro 提交于
      copy_from_iter_full(), copy_from_iter_full_nocache() and
      csum_and_copy_from_iter_full() - counterparts of copy_from_iter()
      et.al., advancing iterator only in case of successful full copy
      and returning whether it had been successful or not.
      
      Convert some obvious users.  *NOTE* - do not blindly assume that
      something is a good candidate for those unless you are sure that
      not advancing iov_iter in failure case is the right thing in
      this case.  Anything that does short read/short write kind of
      stuff (or is in a loop, etc.) is unlikely to be a good one.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      cbbd26b8
  5. 01 12月, 2016 2 次提交
  6. 28 11月, 2016 1 次提交
  7. 19 11月, 2016 1 次提交
  8. 12 8月, 2016 1 次提交
  9. 19 7月, 2016 1 次提交
  10. 16 7月, 2016 2 次提交
  11. 11 6月, 2016 1 次提交
  12. 09 5月, 2016 1 次提交
  13. 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
  14. 27 4月, 2016 1 次提交
  15. 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
  16. 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
  17. 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
  18. 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
  19. 23 10月, 2015 1 次提交
  20. 21 9月, 2015 1 次提交
  21. 28 7月, 2015 1 次提交
  22. 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
  23. 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
  24. 01 6月, 2015 3 次提交
  25. 14 5月, 2015 1 次提交
  26. 13 5月, 2015 1 次提交
  27. 11 5月, 2015 1 次提交
  28. 18 4月, 2015 1 次提交
  29. 12 4月, 2015 1 次提交
  30. 03 3月, 2015 1 次提交
  31. 01 3月, 2015 1 次提交