1. 05 Jul, 2023 17 commits
    • Vlad Buslov's avatar
      net/mlx5e: Check for NOT_READY flag state after locking · 65e64640
      Vlad Buslov authored
      Currently the check for NOT_READY flag is performed before obtaining the
      necessary lock. This opens a possibility for race condition when the flow
      is concurrently removed from unready_flows list by the workqueue task,
      which causes a double-removal from the list and a crash[0]. Fix the issue
      by moving the flag check inside the section protected by
      uplink_priv->unready_flows_lock mutex.
      
      [0]:
      [44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP
      [44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1
      [44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
      [44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]
      [44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06
      [44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246
      [44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00
      [44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0
      [44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001
      [44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000
      [44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000
      [44376.402999] FS:  00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000
      [44376.403787] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0
      [44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [44376.406339] Call Trace:
      [44376.406651]  <TASK>
      [44376.406939]  ? die_addr+0x33/0x90
      [44376.407311]  ? exc_general_protection+0x192/0x390
      [44376.407795]  ? asm_exc_general_protection+0x22/0x30
      [44376.408292]  ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]
      [44376.408876]  __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core]
      [44376.409482]  mlx5e_tc_del_flow+0x42/0x210 [mlx5_core]
      [44376.410055]  mlx5e_flow_put+0x25/0x50 [mlx5_core]
      [44376.410529]  mlx5e_delete_flower+0x24b/0x350 [mlx5_core]
      [44376.411043]  tc_setup_cb_reoffload+0x22/0x80
      [44376.411462]  fl_reoffload+0x261/0x2f0 [cls_flower]
      [44376.411907]  ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]
      [44376.412481]  ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core]
      [44376.413044]  tcf_block_playback_offloads+0x76/0x170
      [44376.413497]  tcf_block_unbind+0x7b/0xd0
      [44376.413881]  tcf_block_setup+0x17d/0x1c0
      [44376.414269]  tcf_block_offload_cmd.isra.0+0xf1/0x130
      [44376.414725]  tcf_block_offload_unbind+0x43/0x70
      [44376.415153]  __tcf_block_put+0x82/0x150
      [44376.415532]  ingress_destroy+0x22/0x30 [sch_ingress]
      [44376.415986]  qdisc_destroy+0x3b/0xd0
      [44376.416343]  qdisc_graft+0x4d0/0x620
      [44376.416706]  tc_get_qdisc+0x1c9/0x3b0
      [44376.417074]  rtnetlink_rcv_msg+0x29c/0x390
      [44376.419978]  ? rep_movs_alternative+0x3a/0xa0
      [44376.420399]  ? rtnl_calcit.isra.0+0x120/0x120
      [44376.420813]  netlink_rcv_skb+0x54/0x100
      [44376.421192]  netlink_unicast+0x1f6/0x2c0
      [44376.421573]  netlink_sendmsg+0x232/0x4a0
      [44376.421980]  sock_sendmsg+0x38/0x60
      [44376.422328]  ____sys_sendmsg+0x1d0/0x1e0
      [44376.422709]  ? copy_msghdr_from_user+0x6d/0xa0
      [44376.423127]  ___sys_sendmsg+0x80/0xc0
      [44376.423495]  ? ___sys_recvmsg+0x8b/0xc0
      [44376.423869]  __sys_sendmsg+0x51/0x90
      [44376.424226]  do_syscall_64+0x3d/0x90
      [44376.424587]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
      [44376.425046] RIP: 0033:0x7f045134f887
      [44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
      [44376.426914] RSP: 002b:00007ffd63a82b98 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      [44376.427592] RAX: ffffffffffffffda RBX: 000000006481955f RCX: 00007f045134f887
      [44376.428195] RDX: 0000000000000000 RSI: 00007ffd63a82c00 RDI: 0000000000000003
      [44376.428796] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
      [44376.429404] R10: 00007f0451208708 R11: 0000000000000246 R12: 0000000000000001
      [44376.430039] R13: 0000000000409980 R14: 000000000047e538 R15: 0000000000485400
      [44376.430644]  </TASK>
      [44376.430907] Modules linked in: mlx5_ib mlx5_core act_mirred act_tunnel_key cls_flower vxlan dummy sch_ingress openvswitch nsh rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_g
      ss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: mlx5_core]
      [44376.433936] ---[ end trace 0000000000000000 ]---
      [44376.434373] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core]
      [44376.434951] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06
      [44376.436452] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246
      [44376.436924] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00
      [44376.437530] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0
      [44376.438179] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001
      [44376.438786] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000
      [44376.439393] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000
      [44376.439998] FS:  00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000
      [44376.440714] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [44376.441225] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0
      [44376.441843] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [44376.442471] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      
      Fixes: ad86755b ("net/mlx5e: Protect unready flows with dedicated lock")
      Signed-off-by: default avatarVlad Buslov <vladbu@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      65e64640
    • Saeed Mahameed's avatar
      net/mlx5: Register a unique thermal zone per device · 631079e0
      Saeed Mahameed authored
      Prior to this patch only one "mlx5" thermal zone could have been
      registered regardless of the number of individual mlx5 devices in the
      system.
      
      To fix this setup a unique name per device to register its own thermal
      zone.
      
      In order to not register a thermal zone for a virtual device (VF/SF) add
      a check for PF device type.
      
      The new name is a concatenation between "mlx5_" and "<PCI_DEV_BDF>", which
      will also help associating a thermal zone with its PCI device.
      
      $ lspci | grep ConnectX
      00:04.0 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6 Dx]
      00:05.0 Ethernet controller: Mellanox Technologies MT2892 Family [ConnectX-6 Dx]
      
      $ cat /sys/devices/virtual/thermal/thermal_zone0/type
      mlx5_0000:00:04.0
      $ cat /sys/devices/virtual/thermal/thermal_zone1/type
      mlx5_0000:00:05.0
      
      Fixes: c1fef618 ("net/mlx5: Implement thermal zone")
      CC: Sandipan Patra <spatra@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      631079e0
    • Dragos Tatulea's avatar
      net/mlx5e: RX, Fix flush and close release flow of regular rq for legacy rq · 2e2d1965
      Dragos Tatulea authored
      Regular (non-XSK) RQs get flushed on XSK setup and re-activated on XSK
      close. If the same regular RQ is closed (a config change for example)
      soon after the XSK close, a double release occurs because the missing
      wqes get released a second time.
      
      Fixes: 3f93f829 ("net/mlx5e: RX, Defer page release in legacy rq for better recycling")
      Signed-off-by: default avatarDragos Tatulea <dtatulea@nvidia.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      2e2d1965
    • Zhengchao Shao's avatar
      net/mlx5e: fix memory leak in mlx5e_ptp_open · d543b649
      Zhengchao Shao authored
      When kvzalloc_node or kvzalloc failed in mlx5e_ptp_open, the memory
      pointed by "c" or "cparams" is not freed, which can lead to a memory
      leak. Fix by freeing the array in the error path.
      
      Fixes: 145e5637 ("net/mlx5e: Add TX PTP port object support")
      Signed-off-by: default avatarZhengchao Shao <shaozhengchao@huawei.com>
      Reviewed-by: default avatarRahul Rameshbabu <rrameshbabu@nvidia.com>
      Reviewed-by: default avatarGal Pressman <gal@nvidia.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      d543b649
    • Zhengchao Shao's avatar
      net/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_create · 3250affd
      Zhengchao Shao authored
      The memory pointed to by the fs->any pointer is not freed in the error
      path of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak.
      Fix by freeing the memory in the error path, thereby making the error path
      identical to mlx5e_fs_tt_redirect_any_destroy().
      
      Fixes: 0f575c20 ("net/mlx5e: Introduce Flow Steering ANY API")
      Signed-off-by: default avatarZhengchao Shao <shaozhengchao@huawei.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Reviewed-by: default avatarRahul Rameshbabu <rrameshbabu@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      3250affd
    • Zhengchao Shao's avatar
      net/mlx5e: fix double free in mlx5e_destroy_flow_table · 884abe45
      Zhengchao Shao authored
      In function accel_fs_tcp_create_groups(), when the ft->g memory is
      successfully allocated but the 'in' memory fails to be allocated, the
      memory pointed to by ft->g is released once. And in function
      accel_fs_tcp_create_table, mlx5e_destroy_flow_table is called to release
      the memory pointed to by ft->g again. This will cause double free problem.
      
      Fixes: c062d52a ("net/mlx5e: Receive flow steering framework for accelerated TCP flows")
      Signed-off-by: default avatarZhengchao Shao <shaozhengchao@huawei.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      884abe45
    • David S. Miller's avatar
      Merge branch 'mptcp-fixes' · c451410c
      David S. Miller authored
      Matthieu Baerts says:
      
      ====================
      mptcp: fixes for v6.5
      
      Here is a first batch of fixes for v6.5 and older.
      
      The fixes are not linked to each others.
      
      Patch 1 ensures subflows are unhashed before cleaning the backlog to
      avoid races. This fixes another recent fix from v6.4.
      
      Patch 2 does not rely on implicit state check in mptcp_listen() to avoid
      races when receiving an MP_FASTCLOSE. A regression from v5.17.
      
      The rest fixes issues in the selftests.
      
      Patch 3 makes sure errors when setting up the environment are no longer
      ignored. For v5.17+.
      
      Patch 4 uses 'iptables-legacy' if available to be able to run on older
      kernels. A fix for v5.13 and newer.
      
      Patch 5 catches errors when issues are detected with packet marks. Also
      for v5.13+.
      
      Patch 6 uses the correct variable instead of an undefined one. Even if
      there was no visible impact, it can help to find regressions later. An
      issue visible in v5.19+.
      
      Patch 7 makes sure errors with some sub-tests are reported to have the
      selftest marked as failed as expected. Also for v5.19+.
      
      Patch 8 adds a kernel config that is required to execute MPTCP
      selftests. It is valid for v5.9+.
      
      Patch 9 fixes issues when validating the userspace path-manager with
      32-bit arch, an issue affecting v5.19+.
      ====================
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      c451410c
    • Matthieu Baerts's avatar
      selftests: mptcp: pm_nl_ctl: fix 32-bit support · 61d96580
      Matthieu Baerts authored
      When using pm_nl_ctl to validate userspace path-manager's behaviours, it
      was failing on 32-bit architectures ~half of the time.
      
      pm_nl_ctl was not reporting any error but the command was not doing what
      it was expected to do. As a result, the expected linked event was not
      triggered after and the test failed.
      
      This is due to the fact the token given in argument to the application
      was parsed as an integer with atoi(): in a 32-bit arch, if the number
      was bigger than INT_MAX, 2147483647 was used instead.
      
      This can simply be fixed by using strtoul() instead of atoi().
      
      The errors have been seen "by chance" when manually looking at the
      results from LKFT.
      
      Fixes: 9a0b3650 ("selftests: mptcp: support MPTCP_PM_CMD_ANNOUNCE")
      Cc: stable@vger.kernel.org
      Fixes: ecd2a77d ("selftests: mptcp: support MPTCP_PM_CMD_REMOVE")
      Fixes: cf8d0a6d ("selftests: mptcp: support MPTCP_PM_CMD_SUBFLOW_CREATE")
      Fixes: 57cc361b ("selftests: mptcp: support MPTCP_PM_CMD_SUBFLOW_DESTROY")
      Fixes: ca188a25 ("selftests: mptcp: userspace PM support for MP_PRIO signals")
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61d96580
    • Matthieu Baerts's avatar
      selftests: mptcp: depend on SYN_COOKIES · 6c8880fc
      Matthieu Baerts authored
      MPTCP selftests are using TCP SYN Cookies for quite a while now, since
      v5.9.
      
      Some CIs don't have this config option enabled and this is causing
      issues in the tests:
      
        # ns1 MPTCP -> ns1 (10.0.1.1:10000      ) MPTCP     (duration   167ms) sysctl: cannot stat /proc/sys/net/ipv4/tcp_syncookies: No such file or directory
        # [ OK ]./mptcp_connect.sh: line 554: [: -eq: unary operator expected
      
      There is no impact in the results but the test is not doing what it is
      supposed to do.
      
      Fixes: fed61c4b ("selftests: mptcp: make 2nd net namespace use tcp syn cookies unconditionally")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c8880fc
    • Matthieu Baerts's avatar
      selftests: mptcp: userspace_pm: report errors with 'remove' tests · 966c6c3a
      Matthieu Baerts authored
      A message was mentioning an issue with the "remove" tests but the
      selftest was not marked as failed.
      
      Directly exit with an error like it is done everywhere else in this
      selftest.
      
      Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368
      Fixes: 259a834f ("selftests: mptcp: functional tests for the userspace PM type")
      Cc: stable@vger.kernel.org
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      966c6c3a
    • Matthieu Baerts's avatar
      selftests: mptcp: userspace_pm: use correct server port · d8566d0e
      Matthieu Baerts authored
      "server4_port" variable is not set but "app4_port" is the server port in
      v4 and the correct variable name to use.
      
      The port is optional so there was no visible impact.
      
      Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368
      Fixes: ca188a25 ("selftests: mptcp: userspace PM support for MP_PRIO signals")
      Cc: stable@vger.kernel.org
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d8566d0e
    • Matthieu Baerts's avatar
      selftests: mptcp: sockopt: return error if wrong mark · 9ac4c28e
      Matthieu Baerts authored
      When an error was detected when checking the marks, a message was
      correctly printed mentioning the error but followed by another one
      saying everything was OK and the selftest was not marked as failed as
      expected.
      
      Now the 'ret' variable is directly set to 1 in order to make sure the
      exit is done with an error, similar to what is done in other functions.
      While at it, the error is correctly propagated to the caller.
      
      Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368
      Fixes: dc65fe82 ("selftests: mptcp: add packet mark test case")
      Cc: stable@vger.kernel.org
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9ac4c28e
    • Matthieu Baerts's avatar
      selftests: mptcp: sockopt: use 'iptables-legacy' if available · a5a5990c
      Matthieu Baerts authored
      IPTables commands using 'iptables-nft' fail on old kernels, at least
      on v5.15 because it doesn't see the default IPTables chains:
      
        $ iptables -L
        iptables/1.8.2 Failed to initialize nft: Protocol not supported
      
      As a first step before switching to NFTables, we can use iptables-legacy
      if available.
      
      Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368
      Fixes: dc65fe82 ("selftests: mptcp: add packet mark test case")
      Cc: stable@vger.kernel.org
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a5a5990c
    • Matthieu Baerts's avatar
      selftests: mptcp: connect: fail if nft supposed to work · 221e4550
      Matthieu Baerts authored
      In case of "external" errors when preparing the environment for the
      TProxy tests, the subtests were marked as skipped.
      
      This is fine but it means these errors are ignored. On MPTCP Public CI,
      we do want to catch such issues and mark the selftest as failed if there
      are such issues. We can then use mptcp_lib_fail_if_expected_feature()
      helper that has been recently added to fail if needed.
      
      Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368
      Fixes: 5fb62e9c ("selftests: mptcp: add tproxy test case")
      Cc: stable@vger.kernel.org
      Acked-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      221e4550
    • Paolo Abeni's avatar
      mptcp: do not rely on implicit state check in mptcp_listen() · 0226436a
      Paolo Abeni authored
      Since the blamed commit, closing the first subflow resets the first
      subflow socket state to SS_UNCONNECTED.
      
      The current mptcp listen implementation relies only on such
      state to prevent touching not-fully-disconnected sockets.
      
      Incoming mptcp fastclose (or paired endpoint removal) unconditionally
      closes the first subflow.
      
      All the above allows an incoming fastclose followed by a listen() call
      to successfully race with a blocking recvmsg(), potentially causing the
      latter to hit a divide by zero bug in cleanup_rbuf/__tcp_select_window().
      
      Address the issue explicitly checking the msk socket state in
      mptcp_listen(). An alternative solution would be moving the first
      subflow socket state update into mptcp_disconnect(), but in the long
      term the first subflow socket should be removed: better avoid relaying
      on it for internal consistency check.
      
      Fixes: b29fcfb5 ("mptcp: full disconnect implementation")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/414Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0226436a
    • Paolo Abeni's avatar
      mptcp: ensure subflow is unhashed before cleaning the backlog · 3fffa15b
      Paolo Abeni authored
      While tacking care of the mptcp-level listener I unintentionally
      moved the subflow level unhash after the subflow listener backlog
      cleanup.
      
      That could cause some nasty race and makes the code harder to read.
      
      Address the issue restoring the proper order of operations.
      
      Fixes: 57fc0f1c ("mptcp: ensure listener is unhashed before updating the sk status")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3fffa15b
    • Thorsten Winkler's avatar
      s390/qeth: Fix vipa deletion · 80de809b
      Thorsten Winkler authored
      Change boolean parameter of function "qeth_l3_vipa_store" inside the
      "qeth_l3_dev_vipa_del4_store" function from "true" to "false" because
      "true" is used for adding a virtual ip address and "false" for deleting.
      
      Fixes: 2390166a ("s390/qeth: clean up L3 sysfs code")
      Reviewed-by: default avatarAlexandra Winter <wintera@linux.ibm.com>
      Reviewed-by: default avatarWenjia Zhang <wenjia@linux.ibm.com>
      Signed-off-by: default avatarThorsten Winkler <twinkler@linux.ibm.com>
      Signed-off-by: default avatarAlexandra Winter <wintera@linux.ibm.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      80de809b
  2. 04 Jul, 2023 8 commits
  3. 03 Jul, 2023 12 commits
    • Rahul Rameshbabu's avatar
      ptp: Make max_phase_adjustment sysfs device attribute invisible when not supported · 2c5d234d
      Rahul Rameshbabu authored
      The .adjphase operation is an operation that is implemented only by certain
      PHCs. The sysfs device attribute node for querying the maximum phase
      adjustment supported should not be exposed on devices that do not support
      .adjphase.
      
      Fixes: c3b60ab7 ("ptp: Add .getmaxphase callback to ptp_clock_info")
      Signed-off-by: default avatarRahul Rameshbabu <rrameshbabu@nvidia.com>
      Reported-by: default avatarNathan Chancellor <nathan@kernel.org>
      Reported-by: default avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      Reported-by: default avatarLinux Kernel Functional Testing <lkft@linaro.org>
      Link: https://lore.kernel.org/netdev/20230627162146.GA114473@dev-arch.thelio-3990X/
      Link: https://lore.kernel.org/all/CA+G9fYtKCZeAUTtwe69iK8Xcz1mOKQzwcy49wd+imZrfj6ifXA@mail.gmail.com/Tested-by: default avatarNathan Chancellor <nathan@kernel.org>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Acked-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Reviewed-by: default avatarPetr Vorel <pvorel@suse.cz>
      Message-ID: <20230627232139.213130-1-rrameshbabu@nvidia.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      2c5d234d
    • Subash Abhinov Kasiviswanathan's avatar
      Documentation: ABI: sysfs-class-net-qmi: pass_through contact update · acd97558
      Subash Abhinov Kasiviswanathan authored
      Switch to the quicinc.com id.
      
      Fixes: bd1af6b5 ("Documentation: ABI: sysfs-class-net-qmi: document pass-through file")
      Signed-off-by: default avatarSubash Abhinov Kasiviswanathan <quic_subashab@quicinc.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      acd97558
    • Eric Dumazet's avatar
      tcp: annotate data races in __tcp_oow_rate_limited() · 998127cd
      Eric Dumazet authored
      request sockets are lockless, __tcp_oow_rate_limited() could be called
      on the same object from different cpus. This is harmless.
      
      Add READ_ONCE()/WRITE_ONCE() annotations to avoid a KCSAN report.
      
      Fixes: 4ce7e93c ("tcp: rate limit ACK sent by SYN_RECV request sockets")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      998127cd
    • David S. Miller's avatar
      Merge branch 'wireguard-fixes' · c94683ed
      David S. Miller authored
      Jason A. Donenfeld says:
      
      ====================
      wireguard fixes for 6.4.2/6.5-rc1
      
      Sorry to send these patches during the merge window, but they're net
      fixes, not netdev enhancements, and while I'd ordinarily wait anyway,
      I just got a first bug report for one of these fixes, which I originally
      had thought was mostly unlikely. So please apply the following three
      patches to net:
      
      1) Make proper use of nr_cpu_ids with cpumask_next(), rather than
         awkwardly using modulo, to handle dynamic CPU topology changes.
         Linus noticed this a while ago and pointed it out, and today a user
         actually got hit by it.
      
      2) Respect persistent keepalive and other staged packets when setting
         the private key after the interface is already up.
      
      3) Use timer_delete_sync() instead of del_timer_sync(), per the
         documentation.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c94683ed
    • Jason A. Donenfeld's avatar
      wireguard: timers: move to using timer_delete_sync · 326534e8
      Jason A. Donenfeld authored
      The documentation says that del_timer_sync is obsolete, and code should
      use the equivalent timer_delete_sync instead, so switch to it.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      326534e8
    • Jason A. Donenfeld's avatar
      wireguard: netlink: send staged packets when setting initial private key · f58d0a9b
      Jason A. Donenfeld authored
      Packets bound for peers can queue up prior to the device private key
      being set. For example, if persistent keepalive is set, a packet is
      queued up to be sent as soon as the device comes up. However, if the
      private key hasn't been set yet, the handshake message never sends, and
      no timer is armed to retry, since that would be pointless.
      
      But, if a user later sets a private key, the expectation is that those
      queued packets, such as a persistent keepalive, are actually sent. So
      adjust the configuration logic to account for this edge case, and add a
      test case to make sure this works.
      
      Maxim noticed this with a wg-quick(8) config to the tune of:
      
          [Interface]
          PostUp = wg set %i private-key somefile
      
          [Peer]
          PublicKey = ...
          Endpoint = ...
          PersistentKeepalive = 25
      
      Here, the private key gets set after the device comes up using a PostUp
      script, triggering the bug.
      
      Fixes: e7096c13 ("net: WireGuard secure network tunnel")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarMaxim Cournoyer <maxim.cournoyer@gmail.com>
      Tested-by: default avatarMaxim Cournoyer <maxim.cournoyer@gmail.com>
      Link: https://lore.kernel.org/wireguard/87fs7xtqrv.fsf@gmail.com/Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f58d0a9b
    • Jason A. Donenfeld's avatar
      wireguard: queueing: use saner cpu selection wrapping · 7387943f
      Jason A. Donenfeld authored
      Using `% nr_cpumask_bits` is slow and complicated, and not totally
      robust toward dynamic changes to CPU topologies. Rather than storing the
      next CPU in the round-robin, just store the last one, and also return
      that value. This simplifies the loop drastically into a much more common
      pattern.
      
      Fixes: e7096c13 ("net: WireGuard secure network tunnel")
      Cc: stable@vger.kernel.org
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Tested-by: default avatarManuel Leiner <manuel.leiner@gmx.de>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7387943f
    • J.J. Martzki's avatar
      samples: pktgen: fix append mode failed issue · a27ac539
      J.J. Martzki authored
      Each sample script sources functions.sh before parameters.sh
      which makes $APPEND undefined when trapping EXIT no matter in
      append mode or not. Due to this when sample scripts finished
      they always do "pgctrl reset" which resets pktgen config.
      
      So move trap to each script after sourcing parameters.sh
      and trap EXIT explicitly.
      Signed-off-by: default avatarJ.J. Martzki <mars14850@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a27ac539
    • Daniel Díaz's avatar
      selftests/net: Add xt_policy config for xfrm_policy test · f56d1eea
      Daniel Díaz authored
      When running Kselftests with the current selftests/net/config
      the following problem can be seen with the net:xfrm_policy.sh
      selftest:
      
        # selftests: net: xfrm_policy.sh
        [   41.076721] IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
        [   41.094787] IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
        [   41.107635] IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
        # modprobe: FATAL: Module ip_tables not found in directory /lib/modules/6.1.36
        # iptables v1.8.7 (legacy): can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
        # Perhaps iptables or your kernel needs to be upgraded.
        # modprobe: FATAL: Module ip_tables not found in directory /lib/modules/6.1.36
        # iptables v1.8.7 (legacy): can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
        # Perhaps iptables or your kernel needs to be upgraded.
        # SKIP: Could not insert iptables rule
        ok 1 selftests: net: xfrm_policy.sh # SKIP
      
      This is because IPsec "policy" match support is not available
      to the kernel.
      
      This patch adds CONFIG_NETFILTER_XT_MATCH_POLICY as a module
      to the selftests/net/config file, so that `make
      kselftest-merge` can take this into consideration.
      Signed-off-by: default avatarDaniel Díaz <daniel.diaz@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f56d1eea
    • Eric Dumazet's avatar
      net: fix net_dev_start_xmit trace event vs skb_transport_offset() · f88fcb1d
      Eric Dumazet authored
      After blamed commit, we must be more careful about using
      skb_transport_offset(), as reminded us by syzbot:
      
      WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 skb_transport_offset include/linux/skbuff.h:2977 [inline]
      WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14
      Modules linked in:
      CPU: 0 PID: 10 Comm: kworker/u4:1 Not tainted 6.1.30-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
      Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
      RIP: 0010:skb_transport_header include/linux/skbuff.h:2868 [inline]
      RIP: 0010:skb_transport_offset include/linux/skbuff.h:2977 [inline]
      RIP: 0010:perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14
      Code: 8b 04 25 28 00 00 00 48 3b 84 24 c0 00 00 00 0f 85 4e 04 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc e8 56 22 01 fd <0f> 0b e9 f6 fc ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 86 f9 ff
      RSP: 0018:ffffc900002bf700 EFLAGS: 00010293
      RAX: ffffffff8485d8ca RBX: 000000000000ffff RCX: ffff888100914280
      RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff
      RBP: ffffc900002bf818 R08: ffffffff8485d5b6 R09: fffffbfff0f8fb5e
      R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff110217d8f67
      R13: ffff88810bec7b3a R14: dffffc0000000000 R15: dffffc0000000000
      FS: 0000000000000000(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000
      CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f96cf6d52f0 CR3: 000000012224c000 CR4: 0000000000350ef0
      Call Trace:
      <TASK>
      [<ffffffff84715e35>] trace_net_dev_start_xmit include/trace/events/net.h:14 [inline]
      [<ffffffff84715e35>] xmit_one net/core/dev.c:3643 [inline]
      [<ffffffff84715e35>] dev_hard_start_xmit+0x705/0x980 net/core/dev.c:3660
      [<ffffffff8471a232>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324
      [<ffffffff85416493>] dev_queue_xmit include/linux/netdevice.h:3030 [inline]
      [<ffffffff85416493>] batadv_send_skb_packet+0x3f3/0x680 net/batman-adv/send.c:108
      [<ffffffff85416744>] batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127
      [<ffffffff853bc52a>] batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:393 [inline]
      [<ffffffff853bc52a>] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:421 [inline]
      [<ffffffff853bc52a>] batadv_iv_send_outstanding_bat_ogm_packet+0x69a/0x840 net/batman-adv/bat_iv_ogm.c:1701
      [<ffffffff8151023c>] process_one_work+0x8ac/0x1170 kernel/workqueue.c:2289
      [<ffffffff81511938>] worker_thread+0xaa8/0x12d0 kernel/workqueue.c:2436
      
      Fixes: 66e4c8d9 ("net: warn if transport header was not set")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f88fcb1d
    • Vladimir Oltean's avatar
      net: dsa: tag_sja1105: fix source port decoding in vlan_filtering=0 bridge mode · a398b9ea
      Vladimir Oltean authored
      There was a regression introduced by the blamed commit, where pinging to
      a VLAN-unaware bridge would fail with the repeated message "Couldn't
      decode source port" coming from the tagging protocol driver.
      
      When receiving packets with a bridge_vid as determined by
      dsa_tag_8021q_bridge_join(), dsa_8021q_rcv() will decode:
      - source_port = 0 (which isn't really valid, more like "don't know")
      - switch_id = 0 (which isn't really valid, more like "don't know")
      - vbid = value in range 1-7
      
      Since the blamed patch has reversed the order of the checks, we are now
      going to believe that source_port != -1 and switch_id != -1, so they're
      valid, but they aren't.
      
      The minimal solution to the problem is to only populate source_port and
      switch_id with what dsa_8021q_rcv() came up with, if the vbid is zero,
      i.e. the source port information is trustworthy.
      
      Fixes: c1ae02d8 ("net: dsa: tag_sja1105: always prefer source port information from INCL_SRCPT")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a398b9ea
    • Vladimir Oltean's avatar
      net: bridge: keep ports without IFF_UNICAST_FLT in BR_PROMISC mode · 6ca3c005
      Vladimir Oltean authored
      According to the synchronization rules for .ndo_get_stats() as seen in
      Documentation/networking/netdevices.rst, acquiring a plain spin_lock()
      should not be illegal, but the bridge driver implementation makes it so.
      
      After running these commands, I am being faced with the following
      lockdep splat:
      
      $ ip link add link swp0 name macsec0 type macsec encrypt on && ip link set swp0 up
      $ ip link add dev br0 type bridge vlan_filtering 1 && ip link set br0 up
      $ ip link set macsec0 master br0 && ip link set macsec0 up
      
        ========================================================
        WARNING: possible irq lock inversion dependency detected
        6.4.0-04295-g31b577b4bd4a #603 Not tainted
        --------------------------------------------------------
        swapper/1/0 just changed the state of lock:
        ffff6bd348724cd8 (&br->lock){+.-.}-{3:3}, at: br_forward_delay_timer_expired+0x34/0x198
        but this lock took another, SOFTIRQ-unsafe lock in the past:
         (&ocelot->stats_lock){+.+.}-{3:3}
      
        and interrupts could create inverse lock ordering between them.
      
        other info that might help us debug this:
        Chain exists of:
          &br->lock --> &br->hash_lock --> &ocelot->stats_lock
      
         Possible interrupt unsafe locking scenario:
      
               CPU0                    CPU1
               ----                    ----
          lock(&ocelot->stats_lock);
                                       local_irq_disable();
                                       lock(&br->lock);
                                       lock(&br->hash_lock);
          <Interrupt>
            lock(&br->lock);
      
         *** DEADLOCK ***
      
      (details about the 3 locks skipped)
      
      swp0 is instantiated by drivers/net/dsa/ocelot/felix.c, and this
      only matters to the extent that its .ndo_get_stats64() method calls
      spin_lock(&ocelot->stats_lock).
      
      Documentation/locking/lockdep-design.rst says:
      
      | A lock is irq-safe means it was ever used in an irq context, while a lock
      | is irq-unsafe means it was ever acquired with irq enabled.
      
      (...)
      
      | Furthermore, the following usage based lock dependencies are not allowed
      | between any two lock-classes::
      |
      |    <hardirq-safe>   ->  <hardirq-unsafe>
      |    <softirq-safe>   ->  <softirq-unsafe>
      
      Lockdep marks br->hash_lock as softirq-safe, because it is sometimes
      taken in softirq context (for example br_fdb_update() which runs in
      NET_RX softirq), and when it's not in softirq context it blocks softirqs
      by using spin_lock_bh().
      
      Lockdep marks ocelot->stats_lock as softirq-unsafe, because it never
      blocks softirqs from running, and it is never taken from softirq
      context. So it can always be interrupted by softirqs.
      
      There is a call path through which a function that holds br->hash_lock:
      fdb_add_hw_addr() will call a function that acquires ocelot->stats_lock:
      ocelot_port_get_stats64(). This can be seen below:
      
      ocelot_port_get_stats64+0x3c/0x1e0
      felix_get_stats64+0x20/0x38
      dsa_slave_get_stats64+0x3c/0x60
      dev_get_stats+0x74/0x2c8
      rtnl_fill_stats+0x4c/0x150
      rtnl_fill_ifinfo+0x5cc/0x7b8
      rtmsg_ifinfo_build_skb+0xe4/0x150
      rtmsg_ifinfo+0x5c/0xb0
      __dev_notify_flags+0x58/0x200
      __dev_set_promiscuity+0xa0/0x1f8
      dev_set_promiscuity+0x30/0x70
      macsec_dev_change_rx_flags+0x68/0x88
      __dev_set_promiscuity+0x1a8/0x1f8
      __dev_set_rx_mode+0x74/0xa8
      dev_uc_add+0x74/0xa0
      fdb_add_hw_addr+0x68/0xd8
      fdb_add_local+0xc4/0x110
      br_fdb_add_local+0x54/0x88
      br_add_if+0x338/0x4a0
      br_add_slave+0x20/0x38
      do_setlink+0x3a4/0xcb8
      rtnl_newlink+0x758/0x9d0
      rtnetlink_rcv_msg+0x2f0/0x550
      netlink_rcv_skb+0x128/0x148
      rtnetlink_rcv+0x24/0x38
      
      the plain English explanation for it is:
      
      The macsec0 bridge port is created without p->flags & BR_PROMISC,
      because it is what br_manage_promisc() decides for a VLAN filtering
      bridge with a single auto port.
      
      As part of the br_add_if() procedure, br_fdb_add_local() is called for
      the MAC address of the device, and this results in a call to
      dev_uc_add() for macsec0 while the softirq-safe br->hash_lock is taken.
      
      Because macsec0 does not have IFF_UNICAST_FLT, dev_uc_add() ends up
      calling __dev_set_promiscuity() for macsec0, which is propagated by its
      implementation, macsec_dev_change_rx_flags(), to the lower device: swp0.
      This triggers the call path:
      
      dev_set_promiscuity(swp0)
      -> rtmsg_ifinfo()
         -> dev_get_stats()
            -> ocelot_port_get_stats64()
      
      with a calling context that lockdep doesn't like (br->hash_lock held).
      
      Normally we don't see this, because even though many drivers that can be
      bridge ports don't support IFF_UNICAST_FLT, we need a driver that
      
      (a) doesn't support IFF_UNICAST_FLT, *and*
      (b) it forwards the IFF_PROMISC flag to another driver, and
      (c) *that* driver implements ndo_get_stats64() using a softirq-unsafe
          spinlock.
      
      Condition (b) is necessary because the first __dev_set_rx_mode() calls
      __dev_set_promiscuity() with "bool notify=false", and thus, the
      rtmsg_ifinfo() code path won't be entered.
      
      The same criteria also hold true for DSA switches which don't report
      IFF_UNICAST_FLT. When the DSA master uses a spin_lock() in its
      ndo_get_stats64() method, the same lockdep splat can be seen.
      
      I think the deadlock possibility is real, even though I didn't reproduce
      it, and I'm thinking of the following situation to support that claim:
      
      fdb_add_hw_addr() runs on a CPU A, in a context with softirqs locally
      disabled and br->hash_lock held, and may end up attempting to acquire
      ocelot->stats_lock.
      
      In parallel, ocelot->stats_lock is currently held by a thread B (say,
      ocelot_check_stats_work()), which is interrupted while holding it by a
      softirq which attempts to lock br->hash_lock.
      
      Thread B cannot make progress because br->hash_lock is held by A. Whereas
      thread A cannot make progress because ocelot->stats_lock is held by B.
      
      When taking the issue at face value, the bridge can avoid that problem
      by simply making the ports promiscuous from a code path with a saner
      calling context (br->hash_lock not held). A bridge port without
      IFF_UNICAST_FLT is going to become promiscuous as soon as we call
      dev_uc_add() on it (which we do unconditionally), so why not be
      preemptive and make it promiscuous right from the beginning, so as to
      not be taken by surprise.
      
      With this, we've broken the links between code that holds br->hash_lock
      or br->lock and code that calls into the ndo_change_rx_flags() or
      ndo_get_stats64() ops of the bridge port.
      
      Fixes: 2796d0c6 ("bridge: Automatically manage port promiscuous mode.")
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarIdo Schimmel <idosch@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ca3c005
  4. 02 Jul, 2023 3 commits
    • David S. Miller's avatar
      Merge branch 'octeontx2-af-fixes' · 97791d3c
      David S. Miller authored
      Hariprasad Kelam says:
      
      ====================
      octeontx2-af: MAC block fixes for CN10KB
      
      This patch set contains fixes for the issues encountered in testing
      CN10KB MAC block RPM_USX.
      
      Patch1: firmware to kernel communication is not working due to wrong
              interrupt configuration. CSR addresses are corrected.
      
      Patch2: NIX to RVU PF mapping errors encountered due to wrong firmware
              config. Corrects this mapping error.
      
      Patch3: Driver is trying to access non exist cgx/lmac which is resulting
              in kernel panic. Address this issue by adding proper checks.
      
      Patch4: MAC features are not getting reset on FLR. Fix the issue by
              resetting the stale config.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97791d3c
    • Hariprasad Kelam's avatar
      octeontx2-af: Reset MAC features in FLR · 2e3e94c2
      Hariprasad Kelam authored
      AF driver configures MAC features like internal loopback and PFC upon
      receiving the request from PF and its VF netdev. But these
      features are not getting reset in FLR.  This patch fixes the issue by
      resetting the same.
      
      Fixes: 23999b30 ("octeontx2-af: Enable or disable CGX internal loopback")
      Fixes: 1121f6b0 ("octeontx2-af: Priority flow control configuration support")
      Signed-off-by: default avatarHariprasad Kelam <hkelam@marvell.com>
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e3e94c2
    • Hariprasad Kelam's avatar
      octeontx2-af: Add validation before accessing cgx and lmac · 79ebb537
      Hariprasad Kelam authored
      with the addition of new MAC blocks like CN10K RPM and CN10KB
      RPM_USX, LMACs are noncontiguous and CGX blocks are also
      noncontiguous. But during RVU driver initialization, the driver
      is assuming they are contiguous and trying to access
      cgx or lmac with their id which is resulting in kernel panic.
      
      This patch fixes the issue by adding proper checks.
      
      [   23.219150] pc : cgx_lmac_read+0x38/0x70
      [   23.219154] lr : rvu_program_channels+0x3f0/0x498
      [   23.223852] sp : ffff000100d6fc80
      [   23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27:
      000000000000005a
      [   23.234288] x26: ffff000102586768 x25: 0000000000002500 x24:
      fffffffffff0f000
      
      Fixes: 91c6945e ("octeontx2-af: cn10k: Add RPM MAC support")
      Signed-off-by: default avatarHariprasad Kelam <hkelam@marvell.com>
      Signed-off-by: default avatarSunil Goutham <sgoutham@marvell.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      79ebb537