1. 10 5月, 2016 2 次提交
  2. 09 5月, 2016 4 次提交
  3. 08 5月, 2016 1 次提交
  4. 07 5月, 2016 4 次提交
    • J
      mlxsw: spectrum: Fix ordering in mlxsw_sp_fini · 5113bfdb
      Jiri Pirko 提交于
      Fixes: 0f433fa0 ("mlxsw: spectrum_buffers: Implement shared buffer configuration")
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5113bfdb
    • 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
    • D
      net: vrf: Create FIB tables on link create · b3b4663c
      David Ahern 提交于
      Tables have to exist for VRFs to function. Ensure they exist
      when VRF device is created.
      Signed-off-by: NDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3b4663c
    • J
      cnic: call cp->stop_hw() in cnic_start_hw() on allocation failure · f37bd0cc
      Jon Maxwell 提交于
      We recently had a system crash in the cnic module. Vmcore analysis confirmed
      that "ip link up" was executed which failed due to an allocation failure
      because of memory fragmentation. Futher analysis revealed that the cnic irq
      vector was still allocated after the "ip link up" that failed. When
      "ip link down" was executed it called free_msi_irqs() which crashed the system
      because the cnic irq was still inuse.
      
      PANIC: "kernel BUG at drivers/pci/msi.c:411!"
      
      The code execution was:
      
      cnic_netdev_event()
      if (event == NETDEV_UP) {
      .
      .
             ▹       if (!cnic_start_hw(dev))
      cnic_start_hw()
      calls cnic_cm_open() which failed with -ENOMEM
      cnic_start_hw() then took the err1 path:
      
      err1:
             cp->free_resc(dev); <---- frees resources but not irq vector
             pci_dev_put(dev->pcidev);
             return err;
      }
      
      This returns control back to cnic_netdev_event() but now the cnic irq vector
      is still allocated even although cnic_cm_open() failed. The next
      "ip link down" while trigger the crash.
      
      The cnic_start_hw() routine is not handling the allocation failure correctly.
      Fix this by checking whether CNIC_DRV_STATE_HANDLES_IRQ flag is set indicating
      that the hardware has been started in cnic_start_hw(). If it has then call
      cp->stop_hw() which frees the cnic irq vector and cnic resources. Otherwise
      just maintain the previous behaviour and free cnic resources.
      
      I reproduced this by injecting an ENOMEM error into cnic_cm_alloc_mem()s return
      code.
      
      # ip link set dev enpX down
      # ip link set dev enpX up <--- hit's allocation failure
      # ip link set dev enpX down <--- crashes here
      
      With this patch I confirmed there was no crash in the reproducer.
      Signed-off-by: NJon Maxwell <jmaxwell37@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f37bd0cc
  5. 06 5月, 2016 12 次提交
  6. 05 5月, 2016 17 次提交