1. 03 Jun, 2019 4 commits
    • Florian Westphal's avatar
      net: inetdevice: provide replacement iterators for in_ifaddr walk · ef11db33
      Florian Westphal authored
      The ifa_list is protected either by rcu or rtnl lock, but the
      current iterators do not account for this.
      
      This adds two iterators as replacement, a later patch in
      the series will update them with the needed rcu/rtnl_dereference calls.
      
      Its not done in this patch yet to avoid sparse warnings -- the fields
      lack the proper __rcu annotation.
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef11db33
    • Florian Westphal's avatar
      afs: do not send list of client addresses · 35ebfc22
      Florian Westphal authored
      David Howells says:
        I'm told that there's not really any point populating the list.
        Current OpenAFS ignores it, as does AuriStor - and IBM AFS 3.6 will
        do the right thing.
        The list is actually useless as it's the client's view of the world,
        not the servers, so if there's any NAT in the way its contents are
        invalid.  Further, it doesn't support IPv6 addresses.
      
        On that basis, feel free to make it an empty list and remove all the
        interface enumeration.
      
      V1 of this patch reworked the function to use a new helper for the
      ifa_list iteration to avoid sparse warnings once the proper __rcu
      annotations get added in struct in_device later.
      
      But, in light of the above, just remove afs_get_ipv4_interfaces.
      
      Compile tested only.
      
      Cc: David Howells <dhowells@redhat.com>
      Cc: linux-afs@lists.infradead.org
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Tested-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35ebfc22
    • Colin Ian King's avatar
      qed: remove redundant assignment to rc · b9f88982
      Colin Ian King authored
      The variable rc is assigned with a value that is never read and
      it is re-assigned a new value later on.  The assignment is redundant
      and can be removed.
      
      Addresses-Coverity: ("Unused value")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9f88982
    • David S. Miller's avatar
      Merge tag 'isdn-removal' of https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground · 8a7e8ff8
      David S. Miller authored
      Arnd Bergmann says:
      
      ====================
      isdn: deprecate non-mISDN drivers
      
      When isdn4linux came up in the context of another patch series, I
      remembered that we had discussed removing it a while ago.
      
      It turns out that the suggestion from Karsten Keil wa to remove I4L
      in 2018 after the last public ISDN networks are shut down. This has
      happened now (with a very small number of exceptions), so I guess it's
      time to try again.
      
      We currently have three ISDN stacks in the kernel: the original
      isdn4linux (with the hisax driver), the newer CAPI (with four drivers),
      and finally the mISDN stack (supporting roughly the same hardware as
      hisax).
      
      As far as I can tell, anyone using ISDN with mainline kernel drivers in
      the past few years uses mISDN, and this is typically used for voice-only
      PBX installations that don't require a public network.
      
      The older stacks support additional features for data networks, but those
      typically make no sense any more if there is no network to connect to.
      
      My proposal for this time is to kill off isdn4linux entirely, as it seems
      to have been unusable for quite a while. This code has been abandoned
      for many years and it does cause problems for treewide maintenance as
      it tends to do everything that we try to stop doing.
      Birger Harzenetter mentioned that is is still using i4l in order to
      make use of the 'divert' feature that is not part of mISDN, but has
      otherwise moved on to mISDN for normal operation, like apparently
      everyone else.
      
      CAPI in turn is not quite as obsolete, but two of the drivers (avm
      and hysdn) don't seem to be used at all, while another one (gigaset)
      will stop being maintained as Paul Bolle is no longer able to
      test it after the network gets shut down in September.
      All three are now moved into drivers/staging to let others speak
      up in case there are remaining users.
      This leaves Bluetooth CMTP as the only remaining user of CAPI, but
      Marcel Holtmann wishes to keep maintaining it.
      
      For the discussion on version 1, see [2]
      Unfortunately, Karsten Keil as the maintainer has not participated in
      the discussion.
      
            Arnd
      
      [1] https://patchwork.kernel.org/patch/8484861/#17900371
      [2] https://listserv.isdn4linux.de/pipermail/isdn4linux/2019-April/thread.html
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a7e8ff8
  2. 02 Jun, 2019 4 commits
  3. 01 Jun, 2019 5 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next · c1e9e01d
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter/IPVS updates for net-next
      
      The following patchset container Netfilter/IPVS update for net-next:
      
      1) Add UDP tunnel support for ICMP errors in IPVS.
      
      Julian Anastasov says:
      
      This patchset is a followup to the commit that adds UDP/GUE tunnel:
      "ipvs: allow tunneling with gue encapsulation".
      
      What we do is to put tunnel real servers in hash table (patch 1),
      add function to lookup tunnels (patch 2) and use it to strip the
      embedded tunnel headers from ICMP errors (patch 3).
      
      2) Extend xt_owner to match for supplementary groups, from
         Lukasz Pawelczyk.
      
      3) Remove unused oif field in flow_offload_tuple object, from
         Taehee Yoo.
      
      4) Release basechain counters from workqueue to skip synchronize_rcu()
         call. From Florian Westphal.
      
      5) Replace skb_make_writable() by skb_ensure_writable(). Patchset
         from Florian Westphal.
      
      6) Checksum support for gue encapsulation in IPVS, from Jacky Hu.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c1e9e01d
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · 0462eaac
      David S. Miller authored
      Alexei Starovoitov says:
      
      ====================
      pull-request: bpf-next 2019-05-31
      
      The following pull-request contains BPF updates for your *net-next* tree.
      
      Lots of exciting new features in the first PR of this developement cycle!
      The main changes are:
      
      1) misc verifier improvements, from Alexei.
      
      2) bpftool can now convert btf to valid C, from Andrii.
      
      3) verifier can insert explicit ZEXT insn when requested by 32-bit JITs.
         This feature greatly improves BPF speed on 32-bit architectures. From Jiong.
      
      4) cgroups will now auto-detach bpf programs. This fixes issue of thousands
         bpf programs got stuck in dying cgroups. From Roman.
      
      5) new bpf_send_signal() helper, from Yonghong.
      
      6) cgroup inet skb programs can signal CN to the stack, from Lawrence.
      
      7) miscellaneous cleanups, from many developers.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0462eaac
    • Alan Maguire's avatar
      selftests/bpf: measure RTT from xdp using xdping · cd538502
      Alan Maguire authored
      xdping allows us to get latency estimates from XDP.  Output looks
      like this:
      
      ./xdping -I eth4 192.168.55.8
      Setting up XDP for eth4, please wait...
      XDP setup disrupts network connectivity, hit Ctrl+C to quit
      
      Normal ping RTT data
      [Ignore final RTT; it is distorted by XDP using the reply]
      PING 192.168.55.8 (192.168.55.8) from 192.168.55.7 eth4: 56(84) bytes of data.
      64 bytes from 192.168.55.8: icmp_seq=1 ttl=64 time=0.302 ms
      64 bytes from 192.168.55.8: icmp_seq=2 ttl=64 time=0.208 ms
      64 bytes from 192.168.55.8: icmp_seq=3 ttl=64 time=0.163 ms
      64 bytes from 192.168.55.8: icmp_seq=8 ttl=64 time=0.275 ms
      
      4 packets transmitted, 4 received, 0% packet loss, time 3079ms
      rtt min/avg/max/mdev = 0.163/0.237/0.302/0.054 ms
      
      XDP RTT data:
      64 bytes from 192.168.55.8: icmp_seq=5 ttl=64 time=0.02808 ms
      64 bytes from 192.168.55.8: icmp_seq=6 ttl=64 time=0.02804 ms
      64 bytes from 192.168.55.8: icmp_seq=7 ttl=64 time=0.02815 ms
      64 bytes from 192.168.55.8: icmp_seq=8 ttl=64 time=0.02805 ms
      
      The xdping program loads the associated xdping_kern.o BPF program
      and attaches it to the specified interface.  If run in client
      mode (the default), it will add a map entry keyed by the
      target IP address; this map will store RTT measurements, current
      sequence number etc.  Finally in client mode the ping command
      is executed, and the xdping BPF program will use the last ICMP
      reply, reformulate it as an ICMP request with the next sequence
      number and XDP_TX it.  After the reply to that request is received
      we can measure RTT and repeat until the desired number of
      measurements is made.  This is why the sequence numbers in the
      normal ping are 1, 2, 3 and 8.  We XDP_TX a modified version
      of ICMP reply 4 and keep doing this until we get the 4 replies
      we need; hence the networking stack only sees reply 8, where
      we have XDP_PASSed it upstream since we are done.
      
      In server mode (-s), xdping simply takes ICMP requests and replies
      to them in XDP rather than passing the request up to the networking
      stack.  No map entry is required.
      
      xdping can be run in native XDP mode (the default, or specified
      via -N) or in skb mode (-S).
      
      A test program test_xdping.sh exercises some of these options.
      
      Note that native XDP does not seem to XDP_TX for veths, hence -N
      is not tested.  Looking at the code, it looks like XDP_TX is
      supported so I'm not sure if that's expected.  Running xdping in
      native mode for ixgbe as both client and server works fine.
      
      Changes since v4
      
      - close fds on cleanup (Song Liu)
      
      Changes since v3
      
      - fixed seq to be __be16 (Song Liu)
      - fixed fd checks in xdping.c (Song Liu)
      
      Changes since v2
      
      - updated commit message to explain why seq number of last
        ICMP reply is 8 not 4 (Song Liu)
      - updated types of seq number, raddr and eliminated csum variable
        in xdpclient/xdpserver functions as it was not needed (Song Liu)
      - added XDPING_DEFAULT_COUNT definition and usage specification of
        default/max counts (Song Liu)
      
      Changes since v1
       - moved from RFC to PATCH
       - removed unused variable in ipv4_csum() (Song Liu)
       - refactored ICMP checks into icmp_check() function called by client
         and server programs and reworked client and server programs due
         to lack of shared code (Song Liu)
       - added checks to ensure that SKB and native mode are not requested
         together (Song Liu)
      Signed-off-by: default avatarAlan Maguire <alan.maguire@oracle.com>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      cd538502
    • David S. Miller's avatar
      Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue · 33aae282
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      Intel Wired LAN Driver Updates 2019-05-31
      
      This series contains updates to the iavf driver.
      
      Nathan Chancellor converts the use of gnu_printf to printf.
      
      Aleksandr modifies the driver to limit the number of RSS queues to the
      number of online CPUs in order to avoid creating misconfigured RSS
      queues.
      
      Gustavo A. R. Silva converts a couple of instances where sizeof() can be
      replaced with struct_size().
      
      Alice makes the remaining changes to the iavf driver to cleanup all the
      old "i40evf" references in the driver to iavf, including the file names
      that still contained the old driver reference.  There was no functional
      changes made, just cosmetic to reduce any confusion going forward now
      that the iavf driver is the virtual function driver for both i40e and
      ice drivers.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      33aae282
    • Jiong Wang's avatar
      bpf: doc: update answer for 32-bit subregister question · c231c22a
      Jiong Wang authored
      There has been quite a few progress around the two steps mentioned in the
      answer to the following question:
      
        Q: BPF 32-bit subregister requirements
      
      This patch updates the answer to reflect what has been done.
      
      v2:
       - Add missing full stop. (Song Liu)
       - Minor tweak on one sentence. (Song Liu)
      
      v1:
       - Integrated rephrase from Quentin and Jakub
      Reviewed-by: default avatarQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarJiong Wang <jiong.wang@netronome.com>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      c231c22a
  4. 31 May, 2019 27 commits