1. 24 Jan, 2017 17 commits
  2. 23 Jan, 2017 3 commits
    • Florian Fainelli's avatar
      net: dsa: Check return value of phy_connect_direct() · 4078b76c
      Florian Fainelli authored
      We need to check the return value of phy_connect_direct() in
      dsa_slave_phy_connect() otherwise we may be continuing the
      initialization of a slave network device with a PHY that already
      attached somewhere else and which will soon be in error because the PHY
      device is in error.
      
      The conditions for such an error to occur are that we have a port of our
      switch that is not disabled, and has the same port number as a PHY
      address (say both 5) that can be probed using the DSA slave MII bus. We
      end-up having this slave network device find a PHY at the same address
      as our port number, and we try to attach to it.
      
      A slave network (e.g: port 0) has already attached to our PHY device,
      and we try to re-attach it with a different network device, but since we
      ignore the error we would end-up initializating incorrect device
      references by the time the slave network interface is opened.
      
      The code has been (re)organized several times, making it hard to provide
      an exact Fixes tag, this is a bugfix nonetheless.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4078b76c
    • Florian Fainelli's avatar
      net: phy: Avoid deadlock during phy_error() · eab12771
      Florian Fainelli authored
      phy_error() is called in the PHY state machine workqueue context, and
      calls phy_trigger_machine() which does a cancel_delayed_work_sync() of
      the workqueue we execute from, causing a deadlock situation.
      
      Augment phy_trigger_machine() machine with a sync boolean indicating
      whether we should use cancel_*_sync() or just cancel_*_work().
      
      Fixes: 3c293f4e ("net: phy: Trigger state machine on state change and not polling.")
      Reported-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eab12771
    • David Ahern's avatar
      net: mpls: Fix multipath selection for LSR use case · 9f427a0e
      David Ahern authored
      MPLS multipath for LSR is broken -- always selecting the first nexthop
      in the one label case. For example:
      
          $ ip -f mpls ro ls
          100
                  nexthop as to 200 via inet 172.16.2.2  dev virt12
                  nexthop as to 300 via inet 172.16.3.2  dev virt13
          101
                  nexthop as to 201 via inet6 2000:2::2  dev virt12
                  nexthop as to 301 via inet6 2000:3::2  dev virt13
      
      In this example incoming packets have a single MPLS labels which means
      BOS bit is set. The BOS bit is passed from mpls_forward down to
      mpls_multipath_hash which never processes the hash loop because BOS is 1.
      
      Update mpls_multipath_hash to process the entire label stack. mpls_hdr_len
      tracks the total mpls header length on each pass (on pass N mpls_hdr_len
      is N * sizeof(mpls_shim_hdr)). When the label is found with the BOS set
      it verifies the skb has sufficient header for ipv4 or ipv6, and find the
      IPv4 and IPv6 header by using the last mpls_hdr pointer and adding 1 to
      advance past it.
      
      With these changes I have verified the code correctly sees the label,
      BOS, IPv4 and IPv6 addresses in the network header and icmp/tcp/udp
      traffic for ipv4 and ipv6 are distributed across the nexthops.
      
      Fixes: 1c78efa8 ("mpls: flow-based multipath selection")
      Acked-by: default avatarRobert Shearman <rshearma@brocade.com>
      Signed-off-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f427a0e
  3. 22 Jan, 2017 3 commits
  4. 20 Jan, 2017 11 commits
  5. 19 Jan, 2017 5 commits
  6. 18 Jan, 2017 1 commit
    • Daniel Borkmann's avatar
      bpf: don't trigger OOM killer under pressure with map alloc · d407bd25
      Daniel Borkmann authored
      This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
      that are to be used for map allocations. Using kmalloc() for very large
      allocations can cause excessive work within the page allocator, so i) fall
      back earlier to vmalloc() when the attempt is considered costly anyway,
      and even more importantly ii) don't trigger OOM killer with any of the
      allocators.
      
      Since this is based on a user space request, for example, when creating
      maps with element pre-allocation, we really want such requests to fail
      instead of killing other user space processes.
      
      Also, don't spam the kernel log with warnings should any of the allocations
      fail under pressure. Given that, we can make backend selection in
      bpf_map_area_alloc() generic, and convert all maps over to use this API
      for spots with potentially large allocation requests.
      
      Note, replacing the one kmalloc_array() is fine as overflow checks happen
      earlier in htab_map_alloc(), since it must also protect the multiplication
      for vmalloc() should kmalloc_array() fail.
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d407bd25