1. 28 4月, 2020 1 次提交
  2. 15 4月, 2020 3 次提交
  3. 14 4月, 2020 1 次提交
  4. 08 4月, 2020 3 次提交
    • T
      net: ipv6: do not consider routes via gateways for anycast address check · 03e2a984
      Tim Stallard 提交于
      The behaviour for what is considered an anycast address changed in
      commit 45e4fd26 ("ipv6: Only create RTF_CACHE routes after
      encountering pmtu exception"). This now considers the first
      address in a subnet where there is a route via a gateway
      to be an anycast address.
      
      This breaks path MTU discovery and traceroutes when a host in a
      remote network uses the address at the start of a prefix
      (eg 2600:: advertised as 2600::/48 in the DFZ) as ICMP errors
      will not be sent to anycast addresses.
      
      This patch excludes any routes with a gateway, or via point to
      point links, like the behaviour previously from
      rt6_is_gw_or_nonexthop in net/ipv6/route.c.
      
      This can be tested with:
      ip link add v1 type veth peer name v2
      ip netns add test
      ip netns exec test ip link set lo up
      ip link set v2 netns test
      ip link set v1 up
      ip netns exec test ip link set v2 up
      ip addr add 2001:db8::1/64 dev v1 nodad
      ip addr add 2001:db8:100:: dev lo nodad
      ip netns exec test ip addr add 2001:db8::2/64 dev v2 nodad
      ip netns exec test ip route add unreachable 2001:db8:1::1
      ip netns exec test ip route add 2001:db8:100::/64 via 2001:db8::1
      ip netns exec test sysctl net.ipv6.conf.all.forwarding=1
      ip route add 2001:db8:1::1 via 2001:db8::2
      ping -I 2001:db8::1 2001:db8:1::1 -c1
      ping -I 2001:db8:100:: 2001:db8:1::1 -c1
      ip addr delete 2001:db8:100:: dev lo
      ip netns delete test
      
      Currently the first ping will get back a destination unreachable ICMP
      error, but the second will never get a response, with "icmp6_send:
      acast source" logged. After this patch, both get destination
      unreachable ICMP replies.
      
      Fixes: 45e4fd26 ("ipv6: Only create RTF_CACHE routes after encountering pmtu exception")
      Signed-off-by: NTim Stallard <code@timstallard.me.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      03e2a984
    • L
      net: sock.h: fix skb_steal_sock() kernel-doc · 045065f0
      Lothar Rubusch 提交于
      Fix warnings related to kernel-doc notation, and wording in
      function description.
      Signed-off-by: NLothar Rubusch <l.rubusch@gmail.com>
      Acked-by: NRandy Dunlap <rdunlap@infradead.org>
      Tested-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      045065f0
    • A
      Bluetooth: debugfs option to unset MITM flag · c2aa30db
      Archie Pusaka 提交于
      The BT qualification test SM/MAS/PKE/BV-01-C needs us to turn off
      the MITM flag when pairing, and at the same time also set the io
      capability to something other than no input no output.
      
      Currently the MITM flag is only unset when the io capability is set
      to no input no output, therefore the test cannot be executed.
      
      This patch introduces a debugfs option to force MITM flag to be
      turned off.
      Signed-off-by: NArchie Pusaka <apusaka@chromium.org>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c2aa30db
  5. 06 4月, 2020 1 次提交
  6. 05 4月, 2020 5 次提交
  7. 02 4月, 2020 1 次提交
  8. 31 3月, 2020 10 次提交
  9. 30 3月, 2020 11 次提交
  10. 29 3月, 2020 2 次提交
  11. 28 3月, 2020 2 次提交
    • D
      bpf: Allow to retrieve cgroup v1 classid from v2 hooks · 5a52ae4e
      Daniel Borkmann 提交于
      Today, Kubernetes is still operating on cgroups v1, however, it is
      possible to retrieve the task's classid based on 'current' out of
      connect(), sendmsg(), recvmsg() and bind-related hooks for orchestrators
      which attach to the root cgroup v2 hook in a mixed env like in case
      of Cilium, for example, in order to then correlate certain pod traffic
      and use it as part of the key for BPF map lookups.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/555e1c69db7376c0947007b4951c260e1074efc3.1585323121.git.daniel@iogearbox.net
      5a52ae4e
    • D
      bpf: Add netns cookie and enable it for bpf cgroup hooks · f318903c
      Daniel Borkmann 提交于
      In Cilium we're mainly using BPF cgroup hooks today in order to implement
      kube-proxy free Kubernetes service translation for ClusterIP, NodePort (*),
      ExternalIP, and LoadBalancer as well as HostPort mapping [0] for all traffic
      between Cilium managed nodes. While this works in its current shape and avoids
      packet-level NAT for inter Cilium managed node traffic, there is one major
      limitation we're facing today, that is, lack of netns awareness.
      
      In Kubernetes, the concept of Pods (which hold one or multiple containers)
      has been built around network namespaces, so while we can use the global scope
      of attaching to root BPF cgroup hooks also to our advantage (e.g. for exposing
      NodePort ports on loopback addresses), we also have the need to differentiate
      between initial network namespaces and non-initial one. For example, ExternalIP
      services mandate that non-local service IPs are not to be translated from the
      host (initial) network namespace as one example. Right now, we have an ugly
      work-around in place where non-local service IPs for ExternalIP services are
      not xlated from connect() and friends BPF hooks but instead via less efficient
      packet-level NAT on the veth tc ingress hook for Pod traffic.
      
      On top of determining whether we're in initial or non-initial network namespace
      we also have a need for a socket-cookie like mechanism for network namespaces
      scope. Socket cookies have the nice property that they can be combined as part
      of the key structure e.g. for BPF LRU maps without having to worry that the
      cookie could be recycled. We are planning to use this for our sessionAffinity
      implementation for services. Therefore, add a new bpf_get_netns_cookie() helper
      which would resolve both use cases at once: bpf_get_netns_cookie(NULL) would
      provide the cookie for the initial network namespace while passing the context
      instead of NULL would provide the cookie from the application's network namespace.
      We're using a hole, so no size increase; the assignment happens only once.
      Therefore this allows for a comparison on initial namespace as well as regular
      cookie usage as we have today with socket cookies. We could later on enable
      this helper for other program types as well as we would see need.
      
        (*) Both externalTrafficPolicy={Local|Cluster} types
        [0] https://github.com/cilium/cilium/blob/master/bpf/bpf_sock.cSigned-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/c47d2346982693a9cf9da0e12690453aded4c788.1585323121.git.daniel@iogearbox.net
      f318903c