1. 24 Sep, 2020 1 commit
  2. 21 Sep, 2020 3 commits
  3. 18 Sep, 2020 1 commit
  4. 16 Sep, 2020 4 commits
  5. 15 Sep, 2020 5 commits
    • David Ahern's avatar
      ipv4: Update exception handling for multipath routes via same device · 2fbc6e89
      David Ahern authored
      Kfir reported that pmtu exceptions are not created properly for
      deployments where multipath routes use the same device.
      
      After some digging I see 2 compounding problems:
      1. ip_route_output_key_hash_rcu is updating the flowi4_oif *after*
         the route lookup. This is the second use case where this has
         been a problem (the first is related to use of vti devices with
         VRF). I can not find any reason for the oif to be changed after the
         lookup; the code goes back to the start of git. It does not seem
         logical so remove it.
      
      2. fib_lookups for exceptions do not call fib_select_path to handle
         multipath route selection based on the hash.
      
      The end result is that the fib_lookup used to add the exception
      always creates it based using the first leg of the route.
      
      An example topology showing the problem:
      
                       |  host1
                   +------+
                   | eth0 |  .209
                   +------+
                       |
                   +------+
           switch  | br0  |
                   +------+
                       |
             +---------+---------+
             | host2             |  host3
         +------+             +------+
         | eth0 | .250        | eth0 | 192.168.252.252
         +------+             +------+
      
         +-----+             +-----+
         | vti | .2          | vti | 192.168.247.3
         +-----+             +-----+
             \                  /
       =================================
       tunnels
               192.168.247.1/24
      
      for h in host1 host2 host3; do
              ip netns add ${h}
              ip -netns ${h} link set lo up
              ip netns exec ${h} sysctl -wq net.ipv4.ip_forward=1
      done
      
      ip netns add switch
      ip -netns switch li set lo up
      ip -netns switch link add br0 type bridge stp 0
      ip -netns switch link set br0 up
      
      for n in 1 2 3; do
              ip -netns switch link add eth-sw type veth peer name eth-h${n}
              ip -netns switch li set eth-h${n} master br0 up
              ip -netns switch li set eth-sw netns host${n} name eth0
      done
      
      ip -netns host1 addr add 192.168.252.209/24 dev eth0
      ip -netns host1 link set dev eth0 up
      ip -netns host1 route add 192.168.247.0/24 \
              nexthop via 192.168.252.250 dev eth0 nexthop via 192.168.252.252 dev eth0
      
      ip -netns host2 addr add 192.168.252.250/24 dev eth0
      ip -netns host2 link set dev eth0 up
      
      ip -netns host2 addr add 192.168.252.252/24 dev eth0
      ip -netns host3 link set dev eth0 up
      
      ip netns add tunnel
      ip -netns tunnel li set lo up
      ip -netns tunnel li add br0 type bridge
      ip -netns tunnel li set br0 up
      for n in $(seq 11 20); do
              ip -netns tunnel addr add dev br0 192.168.247.${n}/24
      done
      
      for n in 2 3
      do
              ip -netns tunnel link add vti${n} type veth peer name eth${n}
              ip -netns tunnel link set eth${n} mtu 1360 master br0 up
              ip -netns tunnel link set vti${n} netns host${n} mtu 1360 up
              ip -netns host${n} addr add dev vti${n} 192.168.247.${n}/24
      done
      ip -netns tunnel ro add default nexthop via 192.168.247.2 nexthop via 192.168.247.3
      
      ip netns exec host1 ping -M do -s 1400 -c3 -I 192.168.252.209 192.168.247.11
      ip netns exec host1 ping -M do -s 1400 -c3 -I 192.168.252.209 192.168.247.15
      ip -netns host1 ro ls cache
      
      Before this patch the cache always shows exceptions against the first
      leg in the multipath route; 192.168.252.250 per this example. Since the
      hash has an initial random seed, you may need to vary the final octet
      more than what is listed. In my tests, using addresses between 11 and 19
      usually found 1 that used both legs.
      
      With this patch, the cache will have exceptions for both legs.
      
      Fixes: 4895c771 ("ipv4: Add FIB nexthop exceptions")
      Reported-by: default avatarKfir Itzhak <mastertheknife@gmail.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2fbc6e89
    • Lu Wei's avatar
      net: tipc: kerneldoc fixes · 2e5117ba
      Lu Wei authored
      Fix parameter description of tipc_link_bc_create()
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: 16ad3f40 ("tipc: introduce variable window congestion control")
      Signed-off-by: default avatarLu Wei <luwei32@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e5117ba
    • Dany Madden's avatar
      ibmvnic: update MAINTAINERS · d3f2ef18
      Dany Madden authored
      Update supporters for IBM Power SRIOV Virtual NIC Device Driver.
      Thomas Falcon is moving on to other works. Dany Madden, Lijun Pan
      and Sukadev Bhattiprolu are the current supporters.
      Signed-off-by: default avatarDany Madden <drt@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d3f2ef18
    • Andrii Nakryiko's avatar
      docs/bpf: Remove source code links · 65dce596
      Andrii Nakryiko authored
      Make path to bench_ringbufs.c just a text, not a special link.
      
      Fixes: 97abb2b3 ("docs/bpf: Add BPF ring buffer design notes")
      Reported-by: default avatarMauro Carvalho Chehab <mchehab+huawei@kernel.org>
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200915005031.2748397-1-andriin@fb.com
      65dce596
    • Björn Töpel's avatar
      xsk: Fix number of pinned pages/umem size discrepancy · 2b1667e5
      Björn Töpel authored
      For AF_XDP sockets, there was a discrepancy between the number of of
      pinned pages and the size of the umem region.
      
      The size of the umem region is used to validate the AF_XDP descriptor
      addresses. The logic that pinned the pages covered by the region only
      took whole pages into consideration, creating a mismatch between the
      size and pinned pages. A user could then pass AF_XDP addresses outside
      the range of pinned pages, but still within the size of the region,
      crashing the kernel.
      
      This change correctly calculates the number of pages to be
      pinned. Further, the size check for the aligned mode is
      simplified. Now the code simply checks if the size is divisible by the
      chunk size.
      
      Fixes: bbff2f32 ("xsk: new descriptor addressing scheme")
      Reported-by: default avatarCiara Loftus <ciara.loftus@intel.com>
      Signed-off-by: default avatarBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Tested-by: default avatarCiara Loftus <ciara.loftus@intel.com>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Link: https://lore.kernel.org/bpf/20200910075609.7904-1-bjorn.topel@gmail.com
      2b1667e5
  6. 14 Sep, 2020 13 commits
  7. 12 Sep, 2020 5 commits
  8. 11 Sep, 2020 2 commits
  9. 10 Sep, 2020 6 commits