1. 04 8月, 2021 1 次提交
  2. 03 8月, 2021 1 次提交
  3. 29 7月, 2021 1 次提交
  4. 15 6月, 2021 1 次提交
  5. 13 6月, 2021 1 次提交
    • L
      net: mhi_net: Register wwan_ops for link creation · 13adac03
      Loic Poulain 提交于
      Register wwan_ops for link management via wwan rtnetlink. This is
      only basic support for now, since we only support creating one
      single link (link-0), but is useful to validate new wwan rtnetlink
      interface.
      
      For backward compatibity support, we still register a default netdev
      at probe time, except if 'create_default_iface' module parameter is
      set to false.
      
      This has been tested with iproute2 and mbimcli:
      $ ip link add dev wwan0-0 parentdev-name wwan0 type wwan linkid 0
      $ mbimcli -p -d /dev/wwan0p2MBIM --connect apn=free
      $ ip link set dev wwan0-0 up
      $ ip addr add dev wwan0 ${IP}
      $ ip route replace default via ${IP}
      $ ping 8.8.8.8
      ...
      Signed-off-by: NLoic Poulain <loic.poulain@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      13adac03
  6. 09 6月, 2021 1 次提交
  7. 17 4月, 2021 1 次提交
    • L
      net: Add a WWAN subsystem · 9a44c1cc
      Loic Poulain 提交于
      This change introduces initial support for a WWAN framework. Given the
      complexity and heterogeneity of existing WWAN hardwares and interfaces,
      there is no strict definition of what a WWAN device is and how it should
      be represented. It's often a collection of multiple devices that perform
      the global WWAN feature (netdev, tty, chardev, etc).
      
      One usual way to expose modem controls and configuration is via high
      level protocols such as the well known AT command protocol, MBIM or
      QMI. The USB modems started to expose them as character devices, and
      user daemons such as ModemManager learnt to use them.
      
      This initial version adds the concept of WWAN port, which is a logical
      pipe to a modem control protocol. The protocols are rawly exposed to
      user via character device, allowing straigthforward support in existing
      tools (ModemManager, ofono...). The WWAN core takes care of the generic
      part, including character device management, and relies on port driver
      operations to receive/submit protocol data.
      
      Since the different devices exposing protocols for a same WWAN hardware
      do not necessarily know about each others (e.g. two different USB
      interfaces, PCI/MHI channel devices...) and can be created/removed in
      different orders, the WWAN core ensures that all WAN ports contributing
      to the 'whole' WWAN feature are grouped under the same virtual WWAN
      device, relying on the provided parent device (e.g. mhi controller,
      USB device). It's a 'trick' I copied from Johannes's earlier WWAN
      subsystem proposal.
      
      This initial version is purposely minimalist, it's essentially moving
      the generic part of the previously proposed mhi_wwan_ctrl driver inside
      a common WWAN framework, but the implementation is open and flexible
      enough to allow extension for further drivers.
      Signed-off-by: NLoic Poulain <loic.poulain@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9a44c1cc
  8. 15 3月, 2021 1 次提交
    • I
      netdevsim: Add dummy psample implementation · a8700c3d
      Ido Schimmel 提交于
      Allow netdevsim to report "sampled" packets to the psample module by
      periodically generating packets from a work queue. The behavior can be
      enabled / disabled (default) and the various meta data attributes can be
      controlled via debugfs knobs.
      
      This implementation enables both testing of the psample module with all
      the optional attributes as well as development of user space
      applications on top of psample such as hsflowd and a Wireshark dissector
      for psample generic netlink packets.
      Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8700c3d
  9. 08 3月, 2021 1 次提交
  10. 24 2月, 2021 1 次提交
  11. 27 1月, 2021 1 次提交
  12. 03 1月, 2021 1 次提交
  13. 06 12月, 2020 1 次提交
  14. 06 11月, 2020 1 次提交
  15. 30 10月, 2020 1 次提交
  16. 27 8月, 2020 2 次提交
  17. 02 7月, 2020 1 次提交
    • D
      xen networking: add basic XDP support for xen-netfront · 6c5aa6fc
      Denis Kirjanov 提交于
      The patch adds a basic XDP processing to xen-netfront driver.
      
      We ran an XDP program for an RX response received from netback
      driver. Also we request xen-netback to adjust data offset for
      bpf_xdp_adjust_head() header space for custom headers.
      
      synchronization between frontend and backend parts is done
      by using xenbus state switching:
      Reconfiguring -> Reconfigured- > Connected
      
      UDP packets drop rate using xdp program is around 310 kpps
      using ./pktgen_sample04_many_flows.sh and 160 kpps without the patch.
      Signed-off-by: NDenis Kirjanov <kda@linux-powerpc.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c5aa6fc
  18. 27 6月, 2020 1 次提交
  19. 14 6月, 2020 1 次提交
    • M
      treewide: replace '---help---' in Kconfig files with 'help' · a7f7f624
      Masahiro Yamada 提交于
      Since commit 84af7a61 ("checkpatch: kconfig: prefer 'help' over
      '---help---'"), the number of '---help---' has been gradually
      decreasing, but there are still more than 2400 instances.
      
      This commit finishes the conversion. While I touched the lines,
      I also fixed the indentation.
      
      There are a variety of indentation styles found.
      
        a) 4 spaces + '---help---'
        b) 7 spaces + '---help---'
        c) 8 spaces + '---help---'
        d) 1 space + 1 tab + '---help---'
        e) 1 tab + '---help---'    (correct indentation)
        f) 1 tab + 1 space + '---help---'
        g) 1 tab + 2 spaces + '---help---'
      
      In order to convert all of them to 1 tab + 'help', I ran the
      following commend:
      
        $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'
      Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      a7f7f624
  20. 02 5月, 2020 2 次提交
  21. 01 5月, 2020 1 次提交
  22. 29 4月, 2020 2 次提交
  23. 26 3月, 2020 1 次提交
    • P
      net: Fix CONFIG_NET_CLS_ACT=n and CONFIG_NFT_FWD_NETDEV={y, m} build · 2c64605b
      Pablo Neira Ayuso 提交于
      net/netfilter/nft_fwd_netdev.c: In function ‘nft_fwd_netdev_eval’:
          net/netfilter/nft_fwd_netdev.c:32:10: error: ‘struct sk_buff’ has no member named ‘tc_redirected’
            pkt->skb->tc_redirected = 1;
                    ^~
          net/netfilter/nft_fwd_netdev.c:33:10: error: ‘struct sk_buff’ has no member named ‘tc_from_ingress’
            pkt->skb->tc_from_ingress = 1;
                    ^~
      
      To avoid a direct dependency with tc actions from netfilter, wrap the
      redirect bits around CONFIG_NET_REDIRECT and move helpers to
      include/linux/skbuff.h. Turn on this toggle from the ifb driver, the
      only existing client of these bits in the tree.
      
      This patch adds skb_set_redirected() that sets on the redirected bit
      on the skbuff, it specifies if the packet was redirect from ingress
      and resets the timestamp (timestamp reset was originally missing in the
      netfilter bugfix).
      
      Fixes: bcfabee1 ("netfilter: nft_fwd_netdev: allow to redirect to ifb via ingress")
      Reported-by: noreply@ellerman.id.au
      Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c64605b
  24. 09 3月, 2020 1 次提交
  25. 25 2月, 2020 1 次提交
  26. 17 1月, 2020 1 次提交
  27. 15 1月, 2020 1 次提交
  28. 18 12月, 2019 1 次提交
  29. 17 12月, 2019 1 次提交
  30. 09 12月, 2019 1 次提交
    • J
      net: WireGuard secure network tunnel · e7096c13
      Jason A. Donenfeld 提交于
      WireGuard is a layer 3 secure networking tunnel made specifically for
      the kernel, that aims to be much simpler and easier to audit than IPsec.
      Extensive documentation and description of the protocol and
      considerations, along with formal proofs of the cryptography, are
      available at:
      
        * https://www.wireguard.com/
        * https://www.wireguard.com/papers/wireguard.pdf
      
      This commit implements WireGuard as a simple network device driver,
      accessible in the usual RTNL way used by virtual network drivers. It
      makes use of the udp_tunnel APIs, GRO, GSO, NAPI, and the usual set of
      networking subsystem APIs. It has a somewhat novel multicore queueing
      system designed for maximum throughput and minimal latency of encryption
      operations, but it is implemented modestly using workqueues and NAPI.
      Configuration is done via generic Netlink, and following a review from
      the Netlink maintainer a year ago, several high profile userspace tools
      have already implemented the API.
      
      This commit also comes with several different tests, both in-kernel
      tests and out-of-kernel tests based on network namespaces, taking profit
      of the fact that sockets used by WireGuard intentionally stay in the
      namespace the WireGuard interface was originally created, exactly like
      the semantics of userspace tun devices. See wireguard.com/netns/ for
      pictures and examples.
      
      The source code is fairly short, but rather than combining everything
      into a single file, WireGuard is developed as cleanly separable files,
      making auditing and comprehension easier. Things are laid out as
      follows:
      
        * noise.[ch], cookie.[ch], messages.h: These implement the bulk of the
          cryptographic aspects of the protocol, and are mostly data-only in
          nature, taking in buffers of bytes and spitting out buffers of
          bytes. They also handle reference counting for their various shared
          pieces of data, like keys and key lists.
      
        * ratelimiter.[ch]: Used as an integral part of cookie.[ch] for
          ratelimiting certain types of cryptographic operations in accordance
          with particular WireGuard semantics.
      
        * allowedips.[ch], peerlookup.[ch]: The main lookup structures of
          WireGuard, the former being trie-like with particular semantics, an
          integral part of the design of the protocol, and the latter just
          being nice helper functions around the various hashtables we use.
      
        * device.[ch]: Implementation of functions for the netdevice and for
          rtnl, responsible for maintaining the life of a given interface and
          wiring it up to the rest of WireGuard.
      
        * peer.[ch]: Each interface has a list of peers, with helper functions
          available here for creation, destruction, and reference counting.
      
        * socket.[ch]: Implementation of functions related to udp_socket and
          the general set of kernel socket APIs, for sending and receiving
          ciphertext UDP packets, and taking care of WireGuard-specific sticky
          socket routing semantics for the automatic roaming.
      
        * netlink.[ch]: Userspace API entry point for configuring WireGuard
          peers and devices. The API has been implemented by several userspace
          tools and network management utility, and the WireGuard project
          distributes the basic wg(8) tool.
      
        * queueing.[ch]: Shared function on the rx and tx path for handling
          the various queues used in the multicore algorithms.
      
        * send.c: Handles encrypting outgoing packets in parallel on
          multiple cores, before sending them in order on a single core, via
          workqueues and ring buffers. Also handles sending handshake and cookie
          messages as part of the protocol, in parallel.
      
        * receive.c: Handles decrypting incoming packets in parallel on
          multiple cores, before passing them off in order to be ingested via
          the rest of the networking subsystem with GRO via the typical NAPI
          poll function. Also handles receiving handshake and cookie messages
          as part of the protocol, in parallel.
      
        * timers.[ch]: Uses the timer wheel to implement protocol particular
          event timeouts, and gives a set of very simple event-driven entry
          point functions for callers.
      
        * main.c, version.h: Initialization and deinitialization of the module.
      
        * selftest/*.h: Runtime unit tests for some of the most security
          sensitive functions.
      
        * tools/testing/selftests/wireguard/netns.sh: Aforementioned testing
          script using network namespaces.
      
      This commit aims to be as self-contained as possible, implementing
      WireGuard as a standalone module not needing much special handling or
      coordination from the network subsystem. I expect for future
      optimizations to the network stack to positively improve WireGuard, and
      vice-versa, but for the time being, this exists as intentionally
      standalone.
      
      We introduce a menu option for CONFIG_WIREGUARD, as well as providing a
      verbose debug log and self-tests via CONFIG_WIREGUARD_DEBUG.
      Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Greg KH <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: linux-crypto@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e7096c13
  31. 22 11月, 2019 1 次提交
  32. 26 9月, 2019 1 次提交
  33. 21 5月, 2019 1 次提交
  34. 25 3月, 2019 1 次提交
  35. 19 3月, 2019 1 次提交
  36. 27 2月, 2019 1 次提交
  37. 15 2月, 2019 1 次提交