1. 04 Nov, 2020 27 commits
  2. 03 Nov, 2020 13 commits
    • Ido Schimmel's avatar
      vxlan: Use a per-namespace nexthop listener instead of a global one · 626d667b
      Ido Schimmel authored
      The nexthop notification chain is a per-namespace chain and not a global
      one like the netdev notification chain.
      
      Therefore, a single (global) listener cannot be registered to all these
      chains simultaneously as it will result in list corruptions whenever
      listeners are registered / unregistered.
      
      Instead, register a different listener in each namespace.
      
      Currently this is not an issue because only the VXLAN driver registers a
      listener to this chain, but this is going to change with netdevsim and
      mlxsw also registering their own listeners.
      Signed-off-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@kernel.org>
      Link: https://lore.kernel.org/r/20201101113926.705630-1-idosch@idosch.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      626d667b
    • Jakub Kicinski's avatar
      Merge branch 'net-hdlc_fr-improve-fr_rx-and-add-support-for-any-ethertype' · 12c9ee3c
      Jakub Kicinski authored
      Xie He says:
      
      ====================
      net: hdlc_fr: Improve fr_rx and add support for any Ethertype
      
      The main purpose of this series is the last patch. The previous 4 patches
      are just code clean-ups so that the last patch will not make the code too
      messy. The patches must be applied in sequence.
      
      The receiving code of this driver doesn't support arbitrary Ethertype
      values. It only recognizes a few known Ethertypes when receiving and drops
      skbs with other Ethertypes.
      
      However, the standard document RFC 2427 allows Frame Relay to support any
      Ethertype values. This series adds support for this.
      
      Change from v6:
      Remove the explanation about why only a 2-byte address field is accepted
      because I think it is inadequate and unnecessary.
      
      Change from v5:
      Small fix to the commit messages.
      
      Change from v4:
      Drop the change related to the stats.rx_dropped count.
      Improve the commit message by stating why only a 2-byte address field
      is accepted.
      
      Change from v3:
      Split the last patch into 2 patches.
      Improve the commit message about the stats.rx_dropped count.
      
      Change from v2:
      Small fix to the commit messages.
      
      Change from v1:
      Small fix to the commit messages.
      ====================
      
      Link: https://lore.kernel.org/r/20201031181043.805329-1-xie.he.0141@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      12c9ee3c
    • Xie He's avatar
      net: hdlc_fr: Add support for any Ethertype · 54b77a77
      Xie He authored
      Change the fr_rx function to make this driver support any Ethertype
      when receiving skbs on normal (non-Ethernet-emulating) PVC devices.
      (This driver is already able to handle any Ethertype when sending.)
      
      Originally in the fr_rx function, the code that parses the long (10-byte)
      header only recognizes a few Ethertype values and drops frames with other
      Ethertype values. This patch replaces this code to make fr_rx support
      any Ethertype. This patch also creates a new function fr_snap_parse as
      part of the new code.
      
      Cc: Krzysztof Halasa <khc@pm.waw.pl>
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      54b77a77
    • Xie He's avatar
      net: hdlc_fr: Improve the initial checks when we receive an skb · 77124c44
      Xie He authored
      1.
      Change the skb->len check from "<= 4" to "< 4".
      At first we only need to ensure a 4-byte header is present. We indeed
      normally need the 5th byte, too, but it'd be more logical and cleaner
      to check its existence when we actually need it.
      
      2.
      Add an fh->ea2 check to the initial checks in fr_rx. fh->ea2 == 1 means
      the second address byte is the final address byte. We only support the
      case where the address length is 2 bytes.
      
      Cc: Krzysztof Halasa <khc@pm.waw.pl>
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      77124c44
    • Xie He's avatar
      net: hdlc_fr: Do skb_reset_mac_header for skbs received on normal PVC devices · efc79039
      Xie He authored
      When an skb is received on a normal (non-Ethernet-emulating) PVC device,
      call skb_reset_mac_header before we pass it to upper layers.
      
      This is because normal PVC devices don't have header_ops, so any header we
      have would not be visible to upper layer code when sending, so the header
      shouldn't be visible to upper layer code when receiving, either.
      
      Cc: Krzysztof Halasa <khc@pm.waw.pl>
      Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      efc79039
    • Xie He's avatar
      net: hdlc_fr: Change the use of "dev" in fr_rx to make the code cleaner · 14b20704
      Xie He authored
      The eth_type_trans function is called when we receive frames carrying
      Ethernet frames. This function expects a non-NULL pointer as an argument,
      and assigns it directly to skb->dev.
      
      However, the code handling other types of frames first assigns the pointer
      to "dev", and then at the end checks whether the value is NULL, and if it
      is not NULL, assigns it to skb->dev.
      
      The two flows are different. Mixing them in this function makes the code
      messy. It's better that we convert the second flow to align with how
      eth_type_trans does things.
      
      So this patch changes the code to: first make sure the pointer is not
      NULL, then assign it directly to skb->dev. "dev" is no longer needed until
      the end where we use it to update stats.
      
      Cc: Krzysztof Halasa <khc@pm.waw.pl>
      Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      14b20704
    • Xie He's avatar
      net: hdlc_fr: Simpify fr_rx by using "goto rx_drop" to drop frames · 583d5333
      Xie He authored
      When the fr_rx function drops a received frame (because the protocol type
      is not supported, or because the PVC virtual device that corresponds to
      the DLCI number and the protocol type doesn't exist), the function frees
      the skb and returns.
      
      The code for freeing the skb and returning is repeated several times, this
      patch uses "goto rx_drop" to replace them so that the code looks cleaner.
      
      Cc: Krzysztof Halasa <khc@pm.waw.pl>
      Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      583d5333
    • Lijun Pan's avatar
      ibmvnic: merge do_change_param_reset into do_reset · 16b5f5ce
      Lijun Pan authored
      Commit b27507bb ("net/ibmvnic: unlock rtnl_lock in reset so
      linkwatch_event can run") introduced do_change_param_reset function to
      solve the rtnl lock issue. Majority of the code in do_change_param_reset
      duplicates do_reset. Also, we can handle the rtnl lock issue in do_reset
      itself. Hence merge do_change_param_reset back into do_reset to clean up
      the code.
      Signed-off-by: default avatarLijun Pan <ljp@linux.ibm.com>
      Link: https://lore.kernel.org/r/20201031094645.17255-1-ljp@linux.ibm.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      16b5f5ce
    • Guillaume Nault's avatar
      mpls: drop skb's dst in mpls_forward() · 0992d67b
      Guillaume Nault authored
      Commit 394de110 ("net: Added pointer check for
      dst->ops->neigh_lookup in dst_neigh_lookup_skb") added a test in
      dst_neigh_lookup_skb() to avoid a NULL pointer dereference. The root
      cause was the MPLS forwarding code, which doesn't call skb_dst_drop()
      on incoming packets. That is, if the packet is received from a
      collect_md device, it has a metadata_dst attached to it that doesn't
      implement any dst_ops function.
      
      To align the MPLS behaviour with IPv4 and IPv6, let's drop the dst in
      mpls_forward(). This way, dst_neigh_lookup_skb() doesn't need to test
      ->neigh_lookup any more. Let's keep a WARN condition though, to
      document the precondition and to ease detection of such problems in the
      future.
      Signed-off-by: default avatarGuillaume Nault <gnault@redhat.com>
      Link: https://lore.kernel.org/r/f8c2784c13faa54469a2aac339470b1049ca6b63.1604102750.git.gnault@redhat.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0992d67b
    • Jakub Kicinski's avatar
      Merge branch 'net-mac80211-kernel-enable-kcov-remote-coverage-collection-for-802-11-frame-handling' · 6d89076e
      Jakub Kicinski authored
      Aleksandr Nogikh says:
      
      ====================
      net, mac80211, kernel: enable KCOV remote coverage collection for 802.11 frame handling
      
      This patch series enables remote KCOV coverage collection during
      802.11 frames processing. These changes make it possible to perform
      coverage-guided fuzzing in search of remotely triggerable bugs.
      
      Normally, KCOV collects coverage information for the code that is
      executed inside the system call context. It is easy to identify where
      that coverage should go and whether it should be collected at all by
      looking at the current process. If KCOV was enabled on that process,
      coverage will be stored in a buffer specific to that process.
      Howerever, it is not always enough as handling can happen elsewhere
      (e.g. in separate kernel threads).
      
      When it is impossible to infer KCOV-related info just by looking at
      the currently running process, one needs to manually pass some
      information to the code that should be instrumented. The information
      takes the form of 64 bit integers (KCOV remote handles). Zero is the
      special value that corresponds to an empty handle. More details on
      KCOV and remote coverage collection can be found in
      Documentation/dev-tools/kcov.rst.
      
      The series consists of three commits.
      1. Apply a minor fix to kcov_common_handle() so that it returns a
      valid handle (zero) when called in an interrupt context.
      2. Take the remote handle from KCOV and attach it to newly allocated
      SKBs as an skb extension. If the allocation happens inside a system
      call context, the SKB will be tied to the process that issued the
      syscall (if that process is interested in remote coverage collection).
      3. Annotate the code that processes incoming 802.11 frames with
      kcov_remote_start()/kcov_remote_stop().
      
      v5:
      * Collecting remote coverate at ieee80211_rx_list() instead of
        ieee80211_rx()
      
      v4:
      https://lkml.kernel.org/r/20201028182018.1780842-1-aleksandrnogikh@gmail.com
      * CONFIG_SKB_EXTENSIONS is now automatically selected by CONFIG_KCOV.
      * Elaborated on a minor optimization in skb_set_kcov_handle().
      
      v3:
      https://lkml.kernel.org/r/20201026150851.528148-1-aleksandrnogikh@gmail.com
      * kcov_handle is now stored in skb extensions instead of sk_buff
        itself.
      * Updated the cover letter.
      
      v2:
      https://lkml.kernel.org/r/20201009170202.103512-1-a.nogikh@gmail.com
      * Moved KCOV annotations from ieee80211_tasklet_handler to
        ieee80211_rx.
      * Updated kcov_common_handle() to return 0 if it is called in
        interrupt context.
      * Updated the cover letter.
      
      v1:
      https://lkml.kernel.org/r/20201007101726.3149375-1-a.nogikh@gmail.com
      ====================
      
      Link: https://lore.kernel.org/r/20201029173620.2121359-1-aleksandrnogikh@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6d89076e
    • Aleksandr Nogikh's avatar
      mac80211: add KCOV remote annotations to incoming frame processing · 261e411b
      Aleksandr Nogikh authored
      Add KCOV remote annotations to ieee80211_iface_work() and
      ieee80211_rx_list(). This will enable coverage-guided fuzzing of
      mac80211 code that processes incoming 802.11 frames.
      Signed-off-by: default avatarAleksandr Nogikh <nogikh@google.com>
      Reviewed-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      261e411b
    • Aleksandr Nogikh's avatar
      net: add kcov handle to skb extensions · 6370cc3b
      Aleksandr Nogikh authored
      Remote KCOV coverage collection enables coverage-guided fuzzing of the
      code that is not reachable during normal system call execution. It is
      especially helpful for fuzzing networking subsystems, where it is
      common to perform packet handling in separate work queues even for the
      packets that originated directly from the user space.
      
      Enable coverage-guided frame injection by adding kcov remote handle to
      skb extensions. Default initialization in __alloc_skb and
      __build_skb_around ensures that no socket buffer that was generated
      during a system call will be missed.
      
      Code that is of interest and that performs packet processing should be
      annotated with kcov_remote_start()/kcov_remote_stop().
      
      An alternative approach is to determine kcov_handle solely on the
      basis of the device/interface that received the specific socket
      buffer. However, in this case it would be impossible to distinguish
      between packets that originated during normal background network
      processes or were intentionally injected from the user space.
      Signed-off-by: default avatarAleksandr Nogikh <nogikh@google.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      6370cc3b
    • Aleksandr Nogikh's avatar
      kernel: make kcov_common_handle consider the current context · b08e84da
      Aleksandr Nogikh authored
      kcov_common_handle is a method that is used to obtain a "default" KCOV
      remote handle of the current process. The handle can later be passed
      to kcov_remote_start in order to collect coverage for the processing
      that is initiated by one process, but done in another. For details see
      Documentation/dev-tools/kcov.rst and comments in kernel/kcov.c.
      
      Presently, if kcov_common_handle is called in an IRQ context, it will
      return a handle for the interrupted process. This may lead to
      unreliable and incorrect coverage collection.
      
      Adjust the behavior of kcov_common_handle in the following way. If it
      is called in a task context, return the common handle for the
      currently running task. Otherwise, return 0.
      Signed-off-by: default avatarAleksandr Nogikh <nogikh@google.com>
      Reviewed-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      b08e84da