1. 24 Feb, 2020 11 commits
  2. 23 Feb, 2020 14 commits
  3. 21 Feb, 2020 15 commits
    • David S. Miller's avatar
      Merge branch 'mlxfw-Improve-error-reporting-and-FW-reactivate-support' · 732a0dee
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlxfw: Improve error reporting and FW reactivate support
      
      This patchset improves mlxfw error reporting to netlink and to
      kernel log.
      
      V2:
       - Use proper err codes, EBUSY/EIO instead of EALREADY/EREMOTEIO
       - Fix typo.
      
      From Eran and me.
      
      1) patch #1, Make mlxfw/mlxsw fw flash devlink status notify generic,
         and enable it for mlx5.
      
      2) patches #2..#5 are improving mlxfw flash error messages by
      reporting detailed mlxfw FSM error messages to netlink and kernel log.
      
      3) patches #6,7 From Eran: Add FW reactivate flow to  mlxfw and mlx5
      ====================
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      732a0dee
    • Eran Ben Elisha's avatar
      net/mlx5: Add fsm_reactivate callback support · b7331aa2
      Eran Ben Elisha authored
      Add support for fsm reactivate via MIRC (Management Image Re-activation
      Control) set and query commands.
      For re-activation flow, driver shall first run MIRC set, and then wait
      until FW is done (via querying MIRC status).
      Signed-off-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7331aa2
    • Eran Ben Elisha's avatar
      net/mlxfw: Add reactivate flow support to FSM burn flow · 958dfd0d
      Eran Ben Elisha authored
      Expose fsm_reactivate callback to the mlxfw_dev_ops struct. FSM reactivate
      is needed before flashing the new image in order to flush the old flashed
      but not running firmware image.
      
      In case mlxfw_dev do not support the reactivation, this step will be
      skipped. But if later image flash will fail, a hint will be provided by
      the extack to advise the user that the failure might be related to it.
      Signed-off-by: default avatarEran Ben Elisha <eranbe@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      958dfd0d
    • Saeed Mahameed's avatar
      net/mlxfw: Use MLXFW_ERR_MSG macro for error reporting · 5042e8b9
      Saeed Mahameed authored
      Instead of always calling both mlxfw_err and NL_SET_ERR_MSG_MOD with the
      same message, use the dedicated macro instead.
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5042e8b9
    • Saeed Mahameed's avatar
      net/mlxfw: Convert pr_* to dev_* in mlxfw_fsm.c · 6a3f707c
      Saeed Mahameed authored
      Introduce mlxfw_{info, err, dbg} macros and make them call corresponding
      dev_* macros, then convert all instances of pr_* to mlxfw_*.
      
      This will allow printing the device name mlxfw is operating on.
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6a3f707c
    • Saeed Mahameed's avatar
      net/mlxfw: More error messages coverage · f7fe7aa8
      Saeed Mahameed authored
      Make sure mlxfw_firmware_flash reports a detailed user readable error
      message in every possible error path, basically every time
      mlxfw_dev->ops->*() is called and an error is returned, or when image
      initialization is failed.
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7fe7aa8
    • Saeed Mahameed's avatar
      net/mlxfw: Improve FSM err message reporting and return codes · 86a1270f
      Saeed Mahameed authored
      Report unique and standard error codes corresponding to the specific
      FW flash error. In addition, add a more detailed error messages to
      netlink.
      
      Before:
      $ devlink dev flash pci/0000:05:00.0 file ...
      Error: mlxfw: Firmware flash failed.
      devlink answers: Invalid argument
      
      After:
      $ devlink dev flash pci/0000:05:00.0 file ...
      Error: mlxfw: Firmware flash failed: pending reset.
      devlink answers: Device busy
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      86a1270f
    • Saeed Mahameed's avatar
      net/mlxfw: Generic mlx FW flash status notify · 4ae57566
      Saeed Mahameed authored
      FW flash status notify is currently implemented via a callback to the
      caller mlx module, and all it is doing is to call
      devlink_flash_update_status_notify with the specific module devlink
      instance.
      
      Instead of repeating the whole process for all mlx modules and
      re-implement the status_notify callback again and again. Just provide the
      devlink instance as part of mlxfw_dev when calling mlxfw_firmware_flash
      and let mlxfw do the devlink status updates directly.
      
      This will be very useful for adding status notify support to mlx5, as
      already done in this patch, with a simple one line of just providing the
      devlink instance to mlxfw_firmware_flash.
      
      mlxfw now depends on NET_DEVLINK as all other mlx modules.
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4ae57566
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · b105e8e2
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf-next 2020-02-21
      
      The following pull-request contains BPF updates for your *net-next* tree.
      
      We've added 25 non-merge commits during the last 4 day(s) which contain
      a total of 33 files changed, 2433 insertions(+), 161 deletions(-).
      
      The main changes are:
      
      1) Allow for adding TCP listen sockets into sock_map/hash so they can be used
         with reuseport BPF programs, from Jakub Sitnicki.
      
      2) Add a new bpf_program__set_attach_target() helper for adding libbpf support
         to specify the tracepoint/function dynamically, from Eelco Chaudron.
      
      3) Add bpf_read_branch_records() BPF helper which helps use cases like profile
         guided optimizations, from Daniel Xu.
      
      4) Enable bpf_perf_event_read_value() in all tracing programs, from Song Liu.
      
      5) Relax BTF mandatory check if only used for libbpf itself e.g. to process
         BTF defined maps, from Andrii Nakryiko.
      
      6) Move BPF selftests -mcpu compilation attribute from 'probe' to 'v3' as it has
         been observed that former fails in envs with low memlock, from Yonghong Song.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b105e8e2
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net · e65ee2fb
      David S. Miller authored
      Conflict resolution of ice_virtchnl_pf.c based upon work by
      Stephen Rothwell.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e65ee2fb
    • Daniel Borkmann's avatar
      Merge branch 'bpf-sockmap-listen' · eb1e1478
      Daniel Borkmann authored
      Jakub Sitnicki says:
      
      ====================
      This patch set turns SOCK{MAP,HASH} into generic collections for TCP
      sockets, both listening and established. Adding support for listening
      sockets enables us to use these BPF map types with reuseport BPF programs.
      
      Why? SOCKMAP and SOCKHASH, in comparison to REUSEPORT_SOCKARRAY, allow
      the socket to be in more than one map at the same time.
      
      Having a BPF map type that can hold listening sockets, and gracefully
      co-exist with reuseport BPF is important if, in the future, we want
      BPF programs that run at socket lookup time [0]. Cover letter for v1 of
      this series tells the full story of how we got here [1].
      
      Although SOCK{MAP,HASH} are not a drop-in replacement for SOCKARRAY just
      yet, because UDP support is lacking, it's a step in this direction. We're
      working with Lorenz on extending SOCK{MAP,HASH} to hold UDP sockets, and
      expect to post RFC series for sockmap + UDP in the near future.
      
      I've dropped Acks from all patches that have been touched since v6.
      
      The audit for missing READ_ONCE annotations for access to sk_prot is
      ongoing. Thus far I've found one location specific to TCP listening sockets
      that needed annotating. This got fixed it in this iteration. I wonder if
      sparse checker could be put to work to identify places where we have
      sk_prot access while not holding sk_lock...
      
      The patch series depends on another one, posted earlier [2], that has
      been split out of it.
      
      v6 -> v7:
      
      - Extended the series to cover SOCKHASH. (patches 4-8, 10-11) (John)
      
      - Rebased onto recent bpf-next. Resolved conflicts in recent fixes to
        sk_state checks on sockmap/sockhash update path. (patch 4)
      
      - Added missing READ_ONCE annotation in sock_copy. (patch 1)
      
      - Split out patches that simplify sk_psock_restore_proto [2].
      
      v5 -> v6:
      
      - Added a fix-up for patch 1 which I forgot to commit in v5. Sigh.
      
      v4 -> v5:
      
      - Rebase onto recent bpf-next to resolve conflicts. (Daniel)
      
      v3 -> v4:
      
      - Make tcp_bpf_clone parameter names consistent across function declaration
        and definition. (Martin)
      
      - Use sock_map_redirect_okay helper everywhere we need to take a different
        action for listening sockets. (Lorenz)
      
      - Expand comment explaining the need for a callback from reuseport to
        sockarray code in reuseport_detach_sock. (Martin)
      
      - Mention the possibility of using a u64 counter for reuseport IDs in the
        future in the description for patch 10. (Martin)
      
      v2 -> v3:
      
      - Generate reuseport ID when group is created. Please see patch 10
        description for details. (Martin)
      
      - Fix the build when CONFIG_NET_SOCK_MSG is not selected by either
        CONFIG_BPF_STREAM_PARSER or CONFIG_TLS. (kbuild bot & John)
      
      - Allow updating sockmap from BPF on BPF_SOCK_OPS_TCP_LISTEN_CB callback. An
        oversight in previous iterations. Users may want to populate the sockmap with
        listening sockets from BPF as well.
      
      - Removed RCU read lock assertion in sock_map_lookup_sys. (Martin)
      
      - Get rid of a warning when child socket was cloned with parent's psock
        state. (John)
      
      - Check for tcp_bpf_unhash rather than tcp_bpf_recvmsg when deciding if
        sk_proto needs restoring on clone. Check for recvmsg in the context of
        listening socket cloning was confusing. (Martin)
      
      - Consolidate sock_map_sk_is_suitable with sock_map_update_okay. This led
        to adding dedicated predicates for sockhash. Update self-tests
        accordingly. (John)
      
      - Annotate unlikely branch in bpf_{sk,msg}_redirect_map when socket isn't
        in a map, or isn't a valid redirect target. (John)
      
      - Document paired READ/WRITE_ONCE annotations and cover shared access in
        more detail in patch 2 description. (John)
      
      - Correct a couple of log messages in sockmap_listen self-tests so the
        message reflects the actual failure.
      
      - Rework reuseport tests from sockmap_listen suite so that ENOENT error
        from bpf_sk_select_reuseport handler does not happen on happy path.
      
      v1 -> v2:
      
      - af_ops->syn_recv_sock callback is no longer overridden and burdened with
        restoring sk_prot and clearing sk_user_data in the child socket. As child
        socket is already hashed when syn_recv_sock returns, it is too late to
        put it in the right state. Instead patches 3 & 4 address restoring
        sk_prot and clearing sk_user_data before we hash the child socket.
        (Pointed out by Martin Lau)
      
      - Annotate shared access to sk->sk_prot with READ_ONCE/WRITE_ONCE macros as
        we write to it from sk_msg while socket might be getting cloned on
        another CPU. (Suggested by John Fastabend)
      
      - Convert tests for SOCKMAP holding listening sockets to return-on-error
        style, and hook them up to test_progs. Also use BPF skeleton for setup.
        Add new tests to cover the race scenario discovered during v1 review.
      
      RFC -> v1:
      
      - Switch from overriding proto->accept to af_ops->syn_recv_sock, which
        happens earlier. Clearing the psock state after accept() does not work
        for child sockets that become orphaned (never got accepted). v4-mapped
        sockets need special care.
      
      - Return the socket cookie on SOCKMAP lookup from syscall to be on par with
        REUSEPORT_SOCKARRAY. Requires SOCKMAP to take u64 on lookup/update from
        syscall.
      
      - Make bpf_sk_redirect_map (ingress) and bpf_msg_redirect_map (egress)
        SOCKMAP helpers fail when target socket is a listening one.
      
      - Make bpf_sk_select_reuseport helper fail when target is a TCP established
        socket.
      
      - Teach libbpf to recognize SK_REUSEPORT program type from section name.
      
      - Add a dedicated set of tests for SOCKMAP holding listening sockets,
        covering map operations, overridden socket callbacks, and BPF helpers.
      
      [0] https://lore.kernel.org/bpf/20190828072250.29828-1-jakub@cloudflare.com/
      [1] https://lore.kernel.org/bpf/20191123110751.6729-1-jakub@cloudflare.com/
      [2] https://lore.kernel.org/bpf/20200217121530.754315-1-jakub@cloudflare.com/
      ====================
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      eb1e1478
    • Jakub Sitnicki's avatar
      selftests/bpf: Tests for sockmap/sockhash holding listening sockets · 44d28be2
      Jakub Sitnicki authored
      Now that SOCKMAP and SOCKHASH map types can store listening sockets,
      user-space and BPF API is open to a new set of potential pitfalls.
      
      Exercise the map operations, with extra attention to code paths susceptible
      to races between map ops and socket cloning, and BPF helpers that work with
      SOCKMAP/SOCKHASH to gain confidence that all works as expected.
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20200218171023.844439-12-jakub@cloudflare.com
      44d28be2
    • Jakub Sitnicki's avatar
      selftests/bpf: Extend SK_REUSEPORT tests to cover SOCKMAP/SOCKHASH · 11318ba8
      Jakub Sitnicki authored
      Parametrize the SK_REUSEPORT tests so that the map type for storing sockets
      is not hard-coded in the test setup routine.
      
      This, together with careful state cleaning after the tests, lets us run the
      test cases for REUSEPORT_ARRAY, SOCKMAP, and SOCKHASH to have test coverage
      for all supported map types. The last two support only TCP sockets at the
      moment.
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20200218171023.844439-11-jakub@cloudflare.com
      11318ba8
    • Jakub Sitnicki's avatar
      net: Generate reuseport group ID on group creation · 035ff358
      Jakub Sitnicki authored
      Commit 736b4602 ("net: Add ID (if needed) to sock_reuseport and expose
      reuseport_lock") has introduced lazy generation of reuseport group IDs that
      survive group resize.
      
      By comparing the identifier we check if BPF reuseport program is not trying
      to select a socket from a BPF map that belongs to a different reuseport
      group than the one the packet is for.
      
      Because SOCKARRAY used to be the only BPF map type that can be used with
      reuseport BPF, it was possible to delay the generation of reuseport group
      ID until a socket from the group was inserted into BPF map for the first
      time.
      
      Now that SOCK{MAP,HASH} can be used with reuseport BPF we have two options,
      either generate the reuseport ID on map update, like SOCKARRAY does, or
      allocate an ID from the start when reuseport group gets created.
      
      This patch takes the latter approach to keep sockmap free of calls into
      reuseport code. This streamlines the reuseport_id access as its lifetime
      now matches the longevity of reuseport object.
      
      The cost of this simplification, however, is that we allocate reuseport IDs
      for all SO_REUSEPORT users. Even those that don't use SOCKARRAY in their
      setups. With the way identifiers are currently generated, we can have at
      most S32_MAX reuseport groups, which hopefully is sufficient. If we ever
      get close to the limit, we can switch an u64 counter like sk_cookie.
      
      Another change is that we now always call into SOCKARRAY logic to unlink
      the socket from the map when unhashing or closing the socket. Previously we
      did it only when at least one socket from the group was in a BPF map.
      
      It is worth noting that this doesn't conflict with sockmap tear-down in
      case a socket is in a SOCK{MAP,HASH} and belongs to a reuseport
      group. sockmap tear-down happens first:
      
        prot->unhash
        `- tcp_bpf_unhash
           |- tcp_bpf_remove
           |  `- while (sk_psock_link_pop(psock))
           |     `- sk_psock_unlink
           |        `- sock_map_delete_from_link
           |           `- __sock_map_delete
           |              `- sock_map_unref
           |                 `- sk_psock_put
           |                    `- sk_psock_drop
           |                       `- rcu_assign_sk_user_data(sk, NULL)
           `- inet_unhash
              `- reuseport_detach_sock
                 `- bpf_sk_reuseport_detach
                    `- WRITE_ONCE(sk->sk_user_data, NULL)
      Suggested-by: default avatarMartin Lau <kafai@fb.com>
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200218171023.844439-10-jakub@cloudflare.com
      035ff358
    • Jakub Sitnicki's avatar
      bpf: Allow selecting reuseport socket from a SOCKMAP/SOCKHASH · 9fed9000
      Jakub Sitnicki authored
      SOCKMAP & SOCKHASH now support storing references to listening
      sockets. Nothing keeps us from using these map types a collection of
      sockets to select from in BPF reuseport programs. Whitelist the map types
      with the bpf_sk_select_reuseport helper.
      
      The restriction that the socket has to be a member of a reuseport group
      still applies. Sockets in SOCKMAP/SOCKHASH that don't have sk_reuseport_cb
      set are not a valid target and we signal it with -EINVAL.
      
      The main benefit from this change is that, in contrast to
      REUSEPORT_SOCKARRAY, SOCK{MAP,HASH} don't impose a restriction that a
      listening socket can be just one BPF map at the same time.
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200218171023.844439-9-jakub@cloudflare.com
      9fed9000