1. 12 Jun, 2020 9 commits
    • David S. Miller's avatar
      Merge branch 'net-ipa-endpoint-configuration-fixes' · 18dbd4cd
      David S. Miller authored
      Alex Elder says:
      
      ====================
      net: ipa: endpoint configuration fixes
      
      This series fixes four bugs in the configuration of IPA endpoints.
      See the description of each for more information.
      
      In this version I have dropped the last patch from the series, and
      restored a "static" keyword that had inadvertently gotten removed.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      18dbd4cd
    • Alex Elder's avatar
      net: ipa: header pad field only valid for AP->modem endpoint · f330fda3
      Alex Elder authored
      Only QMAP endpoints should be configured to find a pad size field
      within packet headers.  They are found in the first byte of the QMAP
      header (and the hardware fills only the 6 bits in that byte that
      constitute the pad_len field).
      
      The RMNet driver assumes the pad_len field is valid for received
      packets, so we want to ensure the pad_len field is filled in that
      case.  That driver also assumes the length in the QMAP header
      includes the pad bytes.
      
      The RMNet driver does *not* pad the packets it sends, so the pad_len
      field can be ignored.
      
      Fix ipa_endpoint_init_hdr_ext() so it only marks the pad field
      offset valid for QMAP RX endpoints, and in that case indicates
      that the length field in the header includes the pad bytes.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f330fda3
    • Alex Elder's avatar
      net: ipa: program upper nibbles of sequencer type · 636edeaa
      Alex Elder authored
      The upper two nibbles of the sequencer type were not used for
      SDM845, and were assumed to be 0.  But for SC7180 they are used, and
      so they must be programmed by ipa_endpoint_init_seq().  Fix this bug.
      
      IPA_SEQ_PKT_PROCESS_NO_DEC_NO_UCP_DMAP doesn't have a descriptive
      comment, so add one.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      636edeaa
    • Alex Elder's avatar
      net: ipa: fix modem LAN RX endpoint id · 9b8ad8da
      Alex Elder authored
      The endpoint id assigned to the modem LAN RX endpoint for the SC7180 SoC
      is incorrect.  The erroneous value might have been copied from SDM845 and
      never updated.  The correct endpoint id to use for this SoC is 11.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b8ad8da
    • Alex Elder's avatar
      net: ipa: program metadata mask differently · 8730f45d
      Alex Elder authored
      The way the mask value is programmed for QMAP RX endpoints was based
      on some wrong assumptions about the way metadata containing the QMAP
      mux_id value is formatted.  The metadata value supplied by the
      modem is *not* in QMAP format, and in fact contains the mux_id we
      want in its (big endian) low-order byte.  That byte must be written
      by the IPA into offset 1 of the QMAP header it inserts before the
      received packet.
      
      QMAP TX endpoints *do* use a QMAP header as the metadata sent with
      each packet.  The modem assumes this, and based on that assumes the
      mux_id is in the second byte.  To match those assumptions we must
      program the modem TX (QMAP) endpoint HDR register to indicate the
      metadata will be found at offset 0 in the message header.
      
      The previous configuration managed to work, but it was not working
      correctly.  This patch fixes a bug whose symptom was receipt of
      messages containing the wrong QMAP mux_id.
      
      In fixing this, get rid of ipa_rmnet_mux_id_metadata_mask(), which
      was more or less defined so there was a separate place to explain
      what was happening as we generated the mask value.  Instead, put a
      longer description of how this works above ipa_endpoint_init_hdr(),
      and define the metadata mask to use as a simple constant.
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8730f45d
    • Shannon Nelson's avatar
      ionic: add pcie_print_link_status · c25cba36
      Shannon Nelson authored
      Print the PCIe link information for our device.
      
      Fixes: 77f972a7 ("ionic: remove support for mgmt device")
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c25cba36
    • David S. Miller's avatar
      Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue · 3049f0fd
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      Intel Wired LAN Driver Updates 2020-06-11
      
      This series contains fixes to the iavf driver.
      
      Brett fixes the supported link speeds in the iavf driver, which was only
      able to report speeds that the i40e driver supported and was missing the
      speeds supported by the ice driver.  In addition, fix how 2.5 and 5.0
      GbE speeds are reported.
      
      Alek fixes a enum comparison that was comparing two different enums that
      may have different values, so update the comparison to use matching
      enums.
      
      Paul increases the time to complete a reset to allow for 128 VFs to
      complete a reset.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3049f0fd
    • David S. Miller's avatar
      Merge tag 'mlx5-fixes-2020-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · 07007dbe
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5 fixes 2020-06-11
      
      This series introduces some fixes to mlx5 driver.
      For more information please see tag log below.
      
      Please pull and let me know if there is any problem.
      
      For -stable v5.2
        ('net/mlx5: drain health workqueue in case of driver load error')
      
      For -stable v5.3
        ('net/mlx5e: Fix repeated XSK usage on one channel')
        ('net/mlx5: Fix fatal error handling during device load')
      
      For -stable v5.5
       ('net/mlx5: Disable reload while removing the device')
      
      For -stable v5.7
        ('net/mlx5e: CT: Fix ipv6 nat header rewrite actions')
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      07007dbe
    • David Howells's avatar
      rxrpc: Fix race between incoming ACK parser and retransmitter · 2ad6691d
      David Howells authored
      There's a race between the retransmission code and the received ACK parser.
      The problem is that the retransmission loop has to drop the lock under
      which it is iterating through the transmission buffer in order to transmit
      a packet, but whilst the lock is dropped, the ACK parser can crank the Tx
      window round and discard the packets from the buffer.
      
      The retransmission code then updated the annotations for the wrong packet
      and a later retransmission thought it had to retransmit a packet that
      wasn't there, leading to a NULL pointer dereference.
      
      Fix this by:
      
       (1) Moving the annotation change to before we drop the lock prior to
           transmission.  This means we can't vary the annotation depending on
           the outcome of the transmission, but that's fine - we'll retransmit
           again later if it failed now.
      
       (2) Skipping the packet if the skb pointer is NULL.
      
      The following oops was seen:
      
      	BUG: kernel NULL pointer dereference, address: 000000000000002d
      	Workqueue: krxrpcd rxrpc_process_call
      	RIP: 0010:rxrpc_get_skb+0x14/0x8a
      	...
      	Call Trace:
      	 rxrpc_resend+0x331/0x41e
      	 ? get_vtime_delta+0x13/0x20
      	 rxrpc_process_call+0x3c0/0x4ac
      	 process_one_work+0x18f/0x27f
      	 worker_thread+0x1a3/0x247
      	 ? create_worker+0x17d/0x17d
      	 kthread+0xe6/0xeb
      	 ? kthread_delayed_work_timer_fn+0x83/0x83
      	 ret_from_fork+0x1f/0x30
      
      Fixes: 248f219c ("rxrpc: Rewrite the data and ack handling code")
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2ad6691d
  2. 11 Jun, 2020 22 commits
    • Dan Carpenter's avatar
      net/mlx5: E-Switch, Fix some error pointer dereferences · 09a92975
      Dan Carpenter authored
      We can't leave "counter" set to an error pointer.  Otherwise either it
      will lead to an error pointer dereference later in the function or it
      leads to an error pointer dereference when we call mlx5_fc_destroy().
      
      Fixes: 07bab950 ("net/mlx5: E-Switch, Refactor eswitch ingress acl codes")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      09a92975
    • Leon Romanovsky's avatar
      net/mlx5: Don't fail driver on failure to create debugfs · 17e73d47
      Leon Romanovsky authored
      Clang warns:
      
      drivers/net/ethernet/mellanox/mlx5/core/main.c:1278:6: warning: variable
      'err' is used uninitialized whenever 'if' condition is true
      [-Wsometimes-uninitialized]
              if (!priv->dbg_root) {
                  ^~~~~~~~~~~~~~~
      drivers/net/ethernet/mellanox/mlx5/core/main.c:1303:9: note:
      uninitialized use occurs here
              return err;
                     ^~~
      drivers/net/ethernet/mellanox/mlx5/core/main.c:1278:2: note: remove the
      'if' if its condition is always false
              if (!priv->dbg_root) {
              ^~~~~~~~~~~~~~~~~~~~~~
      drivers/net/ethernet/mellanox/mlx5/core/main.c:1259:9: note: initialize
      the variable 'err' to silence this warning
              int err;
                     ^
                      = 0
      1 warning generated.
      
      The check of returned value of debugfs_create_dir() is wrong because
      by the design debugfs failures should never fail the driver and the
      check itself was wrong too. The kernel compiled without CONFIG_DEBUG_FS
      will return ERR_PTR(-ENODEV) and not NULL as expected.
      
      Fixes: 11f3b84d ("net/mlx5: Split mdev init and pci init")
      Link: https://github.com/ClangBuiltLinux/linux/issues/1042Reported-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      17e73d47
    • Oz Shlomo's avatar
      net/mlx5e: CT: Fix ipv6 nat header rewrite actions · 0d156f2d
      Oz Shlomo authored
      Set the ipv6 word fields according to the hardware definitions.
      
      Fixes: ac991b48 ("net/mlx5e: CT: Offload established flows")
      Signed-off-by: default avatarOz Shlomo <ozsh@mellanox.com>
      Reviewed-by: default avatarRoi Dayan <roid@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      0d156f2d
    • Parav Pandit's avatar
      net/mlx5: Fix devlink objects and devlink device unregister sequence · 98f91c45
      Parav Pandit authored
      Current below problems exists.
      
      1. devlink device is registered by mlx5_load_one(). But it is
      not unregistered by mlx5_unload_one(). This is incorrect.
      
      2. Above issue leads to,
      When mlx5 PCI device is removed, currently devlink device is
      unregistered before devlink ports are unregistered in below ladder
      diagram.
      
      remove_one()
        mlx5_devlink_unregister()
          [..]
          devlink_unregister() <- ports are still registered!
        mlx5_unload_one()
          mlx5_unregister_device()
            mlx5_remove_device()
              mlx5e_remove()
                mlx5e_devlink_port_unregister()
                  devlink_port_unregister()
      
      3. Condition checking for registering and unregister device are not
      symmetric either in these routines.
      
      Hence, fix the sequence by having load and unload routines symmetric
      and in right order.
      i.e.
      (a) register devlink device followed by registering devlink ports
      (b) unregister devlink ports followed by devlink device
      
      Do this based on boot and cleanup flags instead of different
      conditions.
      
      Fixes: c6acd629 ("net/mlx5e: Add support for devlink-port in non-representors mode")
      Fixes: f60f315d ("net/mlx5e: Register devlink ports for physical link, PCI PF, VFs")
      Signed-off-by: default avatarParav Pandit <parav@mellanox.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      98f91c45
    • Parav Pandit's avatar
      net/mlx5: Disable reload while removing the device · 60904cd3
      Parav Pandit authored
      While unregistration is in progress, user might be reloading the
      interface.
      This can race with unregistration in below flow which uses the
      resources which are getting disabled by reload flow.
      
      Hence, disable the devlink reloading first when removing the device.
      
           CPU0                                   CPU1
           ----                                   ----
      local_pci_remove()                  devlink_mutex
        remove_one()                       devlink_nl_cmd_reload()
          mlx5_unregister_device()           devlink_reload()
                                             ops->reload_down()
                                               mlx5_unload_one()
      
      Fixes: 4383cfcc ("net/mlx5: Add devlink reload")
      Signed-off-by: default avatarParav Pandit <parav@mellanox.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      60904cd3
    • Aya Levin's avatar
      net/mlx5e: Fix ethtool hfunc configuration change · 5f1572e6
      Aya Levin authored
      Changing RX hash function requires rearranging of RQT internal indexes,
      the user isn't exposed to such changes and these changes do not affect
      the user configured indirection table. Rebuild RQ table on hfunc change.
      
      Fixes: bdfc028d ("net/mlx5e: Fix ethtool RX hash func configuration change")
      Signed-off-by: default avatarAya Levin <ayal@mellanox.com>
      Reviewed-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      5f1572e6
    • Maxim Mikityanskiy's avatar
      net/mlx5e: Fix repeated XSK usage on one channel · 36d45fb9
      Maxim Mikityanskiy authored
      After an XSK is closed, the relevant structures in the channel are not
      zeroed. If an XSK is opened the second time on the same channel without
      recreating channels, the stray values in the structures will lead to
      incorrect operation of queues, which causes CQE errors, and the new
      socket doesn't work at all.
      
      This patch fixes the issue by explicitly zeroing XSK-related structs in
      the channel on XSK close. Note that those structs are zeroed on channel
      creation, and usually a configuration change (XDP program is set)
      happens on XSK open, which leads to recreating channels, so typical XSK
      usecases don't suffer from this issue. However, if XSKs are opened and
      closed on the same channel without removing the XDP program, this bug
      reproduces.
      
      Fixes: db05815b ("net/mlx5e: Add XSK zero-copy support")
      Signed-off-by: default avatarMaxim Mikityanskiy <maximmi@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      36d45fb9
    • Denis Efremov's avatar
      net/mlx5: DR, Fix freeing in dr_create_rc_qp() · 47a357de
      Denis Efremov authored
      Variable "in" in dr_create_rc_qp() is allocated with kvzalloc() and
      should be freed with kvfree().
      
      Fixes: 297ccceb ("net/mlx5: DR, Expose an internal API to issue RDMA operations")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDenis Efremov <efremov@linux.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      47a357de
    • Shay Drory's avatar
      net/mlx5: Fix fatal error handling during device load · b6e0b6be
      Shay Drory authored
      Currently, in case of fatal error during mlx5_load_one(), we cannot
      enter error state until mlx5_load_one() is finished, what can take
      several minutes until commands will get timeouts, because these commands
      can't be processed due to the fatal error.
      Fix it by setting dev->state as MLX5_DEVICE_STATE_INTERNAL_ERROR before
      requesting the lock.
      
      Fixes: c1d4d2e9 ("net/mlx5: Avoid calling sleeping function by the health poll thread")
      Signed-off-by: default avatarShay Drory <shayd@mellanox.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      b6e0b6be
    • Shay Drory's avatar
      net/mlx5: drain health workqueue in case of driver load error · 42ea9f1b
      Shay Drory authored
      In case there is a work in the health WQ when we teardown the driver,
      in driver load error flow, the health work will try to read dev->iseg,
      which was already unmap in mlx5_pci_close().
      Fix it by draining the health workqueue first thing in mlx5_pci_close().
      
      Trace of the error:
      BUG: unable to handle page fault for address: ffffb5b141c18014
      PF: supervisor read access in kernel mode
      PF: error_code(0x0000) - not-present page
      PGD 1fe95d067 P4D 1fe95d067 PUD 1fe95e067 PMD 1b7823067 PTE 0
      Oops: 0000 [#1] SMP PTI
      CPU: 3 PID: 6755 Comm: kworker/u128:2 Not tainted 5.2.0-net-next-mlx5-hv_stats-over-last-worked-hyperv #1
      Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006  04/28/2016
      Workqueue: mlx5_healtha050:00:02.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]
      RIP: 0010:ioread32be+0x30/0x40
      Code: 00 77 27 48 81 ff 00 00 01 00 76 07 0f b7 d7 ed 0f c8 c3 55 48 c7 c6 3b ee d5 9f 48 89 e5 e8 67 fc ff ff b8 ff ff ff ff 5d c3 <8b> 07 0f c8 c3 66 66 2e 0f 1f 84 00 00 00 00 00 48 81 fe ff ff 03
      RSP: 0018:ffffb5b14c56fd78 EFLAGS: 00010292
      RAX: ffffb5b141c18000 RBX: ffff8e9f78a801c0 RCX: 0000000000000000
      RDX: 0000000000000001 RSI: ffff8e9f7ecd7628 RDI: ffffb5b141c18014
      RBP: ffffb5b14c56fd90 R08: 0000000000000001 R09: 0000000000000000
      R10: ffff8e9f372a2c30 R11: ffff8e9f87f4bc40 R12: ffff8e9f372a1fc0
      R13: ffff8e9f78a80000 R14: ffffffffc07136a0 R15: ffff8e9f78ae6f20
      FS:  0000000000000000(0000) GS:ffff8e9f7ecc0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffb5b141c18014 CR3: 00000001c8f82006 CR4: 00000000003606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       ? mlx5_health_try_recover+0x4d/0x270 [mlx5_core]
       mlx5_fw_fatal_reporter_recover+0x16/0x20 [mlx5_core]
       devlink_health_reporter_recover+0x1c/0x50
       devlink_health_report+0xfb/0x240
       mlx5_fw_fatal_reporter_err_work+0x65/0xd0 [mlx5_core]
       process_one_work+0x1fb/0x4e0
       ? process_one_work+0x16b/0x4e0
       worker_thread+0x4f/0x3d0
       kthread+0x10d/0x140
       ? process_one_work+0x4e0/0x4e0
       ? kthread_cancel_delayed_work_sync+0x20/0x20
       ret_from_fork+0x1f/0x30
      Modules linked in: nfsv3 rpcsec_gss_krb5 nfsv4 nfs fscache 8021q garp mrp stp llc ipmi_devintf ipmi_msghandler rpcrdma rdma_ucm ib_iser rdma_cm ib_umad iw_cm ib_ipoib libiscsi scsi_transport_iscsi ib_cm mlx5_ib ib_uverbs ib_core mlx5_core sb_edac crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 mlxfw crypto_simd cryptd glue_helper input_leds hyperv_fb intel_rapl_perf joydev serio_raw pci_hyperv pci_hyperv_mini mac_hid hv_balloon nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel ip_tables x_tables autofs4 hv_utils hid_generic hv_storvsc ptp hid_hyperv hid hv_netvsc hyperv_keyboard pps_core scsi_transport_fc psmouse hv_vmbus i2c_piix4 floppy pata_acpi
      CR2: ffffb5b141c18014
      ---[ end trace b12c5503157cad24 ]---
      RIP: 0010:ioread32be+0x30/0x40
      Code: 00 77 27 48 81 ff 00 00 01 00 76 07 0f b7 d7 ed 0f c8 c3 55 48 c7 c6 3b ee d5 9f 48 89 e5 e8 67 fc ff ff b8 ff ff ff ff 5d c3 <8b> 07 0f c8 c3 66 66 2e 0f 1f 84 00 00 00 00 00 48 81 fe ff ff 03
      RSP: 0018:ffffb5b14c56fd78 EFLAGS: 00010292
      RAX: ffffb5b141c18000 RBX: ffff8e9f78a801c0 RCX: 0000000000000000
      RDX: 0000000000000001 RSI: ffff8e9f7ecd7628 RDI: ffffb5b141c18014
      RBP: ffffb5b14c56fd90 R08: 0000000000000001 R09: 0000000000000000
      R10: ffff8e9f372a2c30 R11: ffff8e9f87f4bc40 R12: ffff8e9f372a1fc0
      R13: ffff8e9f78a80000 R14: ffffffffc07136a0 R15: ffff8e9f78ae6f20
      FS:  0000000000000000(0000) GS:ffff8e9f7ecc0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffb5b141c18014 CR3: 00000001c8f82006 CR4: 00000000003606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      BUG: sleeping function called from invalid context at ./include/linux/percpu-rwsem.h:38
      in_atomic(): 0, irqs_disabled(): 1, pid: 6755, name: kworker/u128:2
      INFO: lockdep is turned off.
      CPU: 3 PID: 6755 Comm: kworker/u128:2 Tainted: G      D           5.2.0-net-next-mlx5-hv_stats-over-last-worked-hyperv #1
      Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006  04/28/2016
      Workqueue: mlx5_healtha050:00:02.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]
      Call Trace:
       dump_stack+0x63/0x88
       ___might_sleep+0x10a/0x130
       __might_sleep+0x4a/0x80
       exit_signals+0x33/0x230
       ? blocking_notifier_call_chain+0x16/0x20
       do_exit+0xb1/0xc30
       ? kthread+0x10d/0x140
       ? process_one_work+0x4e0/0x4e0
      
      Fixes: 52c368dc ("net/mlx5: Move health and page alloc init to mdev_init")
      Signed-off-by: default avatarShay Drory <shayd@mellanox.com>
      Reviewed-by: default avatarMoshe Shemesh <moshe@mellanox.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      42ea9f1b
    • Paul Greenwalt's avatar
      iavf: increase reset complete wait time · 8e3e4b9d
      Paul Greenwalt authored
      With an increased number of VFs, it's possible to encounter the following
      issue during reset.
      
          iavf b8d4:00:02.0: Hardware reset detected
          iavf b8d4:00:02.0: Reset never finished (0)
          iavf b8d4:00:02.0: Reset task did not complete, VF disabled
      
      Increase the reset complete wait count to allow for 128 VFs to complete
      reset.
      Signed-off-by: default avatarPaul Greenwalt <paul.greenwalt@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8e3e4b9d
    • Brett Creeley's avatar
      iavf: Fix reporting 2.5 Gb and 5Gb speeds · 18c012d9
      Brett Creeley authored
      Commit 4ae4916b ("i40e: fix 'Unknown bps' in dmesg for 2.5Gb/5Gb
      speeds") added the ability for the PF to report 2.5 and 5Gb speeds,
      however, the iavf driver does not recognize those speeds as the values were
      not added there. Add the proper enums and values so that iavf can properly
      deal with those speeds.
      
      Fixes: 4ae4916b ("i40e: fix 'Unknown bps' in dmesg for 2.5Gb/5Gb speeds")
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Signed-off-by: default avatarWitold Fijalkowski <witoldx.fijalkowski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      18c012d9
    • Aleksandr Loktionov's avatar
      iavf: use appropriate enum for comparison · 5071bda2
      Aleksandr Loktionov authored
      adapter->link_speed has type enum virtchnl_link_speed but our comparisons
      are against enum iavf_aq_link_speed. Though they are, currently, the same
      values, change the comparison to the matching enum virtchnl_link_speed
      since that may not always be the case.
      Signed-off-by: default avatarAleksandr Loktionov <aleksandr.loktionov@intel.com>
      Signed-off-by: default avatarPiotr Kwapulinski <piotr.kwapulinski@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5071bda2
    • Brett Creeley's avatar
      iavf: fix speed reporting over virtchnl · e0ef26fb
      Brett Creeley authored
      Link speeds are communicated over virtchnl using an enum
      virtchnl_link_speed. Currently, the highest link speed is 40Gbps which
      leaves us unable to reflect some speeds that an ice VF is capable of.
      This causes link speed to be misreported on the iavf driver.
      
      Allow for communicating link speeds using Mbps so that the proper speed can
      be reported for an ice VF. Moving away from the enum allows us to
      communicate future speed changes without requiring a new enum to be added.
      
      In order to support communicating link speeds over virtchnl in Mbps the
      following functionality was added:
          - Added u32 link_speed_mbps in the iavf_adapter structure.
          - Added the macro ADV_LINK_SUPPORT(_a) to determine if the VF
            driver supports communicating link speeds in Mbps.
          - Added the function iavf_get_vpe_link_status() to fill the
            correct link_status in the event_data union based on the
            ADV_LINK_SUPPORT(_a) macro.
          - Added the function iavf_set_adapter_link_speed_from_vpe()
            to determine whether or not to fill the u32 link_speed_mbps or
            enum virtchnl_link_speed link_speed field in the iavf_adapter
            structure based on the ADV_LINK_SUPPORT(_a) macro.
          - Do not free vf_res in iavf_init_get_resources() as vf_res will be
            accessed in iavf_get_link_ksettings(); memset to 0 instead. This
            memory is subsequently freed in iavf_remove().
      
      Fixes: 7c710869 ("ice: Add handlers for VF netdevice operations")
      Signed-off-by: default avatarBrett Creeley <brett.creeley@intel.com>
      Signed-off-by: default avatarSergey Nemov <sergey.nemov@intel.com>
      Signed-off-by: default avatarPaul Greenwalt <paul.greenwalt@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e0ef26fb
    • Tuong Lien's avatar
      tipc: fix NULL pointer dereference in tipc_disc_rcv() · 97982782
      Tuong Lien authored
      When a bearer is enabled, we create a 'tipc_discoverer' object to store
      the bearer related data along with a timer and a preformatted discovery
      message buffer for later probing... However, this is only carried after
      the bearer was set 'up', that left a race condition resulting in kernel
      panic.
      
      It occurs when a discovery message from a peer node is received and
      processed in bottom half (since the bearer is 'up' already) just before
      the discoverer object is created but is now accessed in order to update
      the preformatted buffer (with a new trial address, ...) so leads to the
      NULL pointer dereference.
      
      We solve the problem by simply moving the bearer 'up' setting to later,
      so make sure everything is ready prior to any message receiving.
      Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
      Signed-off-by: default avatarTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97982782
    • Tuong Lien's avatar
      tipc: fix kernel WARNING in tipc_msg_append() · c9aa81fa
      Tuong Lien authored
      syzbot found the following issue:
      
      WARNING: CPU: 0 PID: 6808 at include/linux/thread_info.h:150 check_copy_size include/linux/thread_info.h:150 [inline]
      WARNING: CPU: 0 PID: 6808 at include/linux/thread_info.h:150 copy_from_iter include/linux/uio.h:144 [inline]
      WARNING: CPU: 0 PID: 6808 at include/linux/thread_info.h:150 tipc_msg_append+0x49a/0x5e0 net/tipc/msg.c:242
      Kernel panic - not syncing: panic_on_warn set ...
      
      This happens after commit 5e9eeccc ("tipc: fix NULL pointer
      dereference in streaming") that tried to build at least one buffer even
      when the message data length is zero... However, it now exposes another
      bug that the 'mss' can be zero and the 'cpy' will be negative, thus the
      above kernel WARNING will appear!
      The zero value of 'mss' is never expected because it means Nagle is not
      enabled for the socket (actually the socket type was 'SOCK_SEQPACKET'),
      so the function 'tipc_msg_append()' must not be called at all. But that
      was in this particular case since the message data length was zero, and
      the 'send <= maxnagle' check became true.
      
      We resolve the issue by explicitly checking if Nagle is enabled for the
      socket, i.e. 'maxnagle != 0' before calling the 'tipc_msg_append()'. We
      also reinforce the function to against such a negative values if any.
      
      Reported-by: syzbot+75139a7d2605236b0b7f@syzkaller.appspotmail.com
      Fixes: c0bceb97 ("tipc: add smart nagle feature")
      Acked-by: default avatarJon Maloy <jmaloy@redhat.com>
      Signed-off-by: default avatarTuong Lien <tuong.t.lien@dektech.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c9aa81fa
    • Shannon Nelson's avatar
      ionic: remove support for mgmt device · 77f972a7
      Shannon Nelson authored
      We no longer support the mgmt device in the ionic driver,
      so remove the device id and related code.
      
      Fixes: b3f064e9 ("ionic: add support for device id 0x1004")
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      77f972a7
    • Xu Wang's avatar
      drivers: dpaa2: Use devm_kcalloc() in setup_dpni() · 9334d5ba
      Xu Wang authored
      A multiplication for the size determination of a memory allocation
      indicated that an array data structure should be processed.
      Thus use the corresponding function "devm_kcalloc".
      Signed-off-by: default avatarXu Wang <vulab@iscas.ac.cn>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9334d5ba
    • Jakub Kicinski's avatar
      docs: networkng: convert sja1105's devlink info to RTS · ae0b829d
      Jakub Kicinski authored
      A new file snuck into the tree after all existing documentation
      was converted to RST. Convert sja1105's devlink info and move
      it where the rest of the drivers are documented.
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Acked-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Tested-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae0b829d
    • David S. Miller's avatar
      Merge branch 'chcr-Fixing-issues-in-dma-mapping-and-driver-removal' · b548493c
      David S. Miller authored
      Ayush Sawal says:
      
      ====================
      Fixing issues in dma mapping and driver removal
      
      Patch 1: This fixes the kernel panic which occurs due to the accessing
      of a zero length sg.
      
      Patch 2: Avoiding unregistering the algorithm if cra_refcnt is not 1.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b548493c
    • Ayush Sawal's avatar
      Crypto/chcr: Checking cra_refcnt before unregistering the algorithms · 8b9914cd
      Ayush Sawal authored
      This patch puts a check for algorithm unregister, to avoid removal of
      driver if the algorithm is under use.
      Signed-off-by: default avatarAyush Sawal <ayush.sawal@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b9914cd
    • Ayush Sawal's avatar
      Crypto/chcr: Calculate src and dst sg lengths separately for dma map · fb90a1c8
      Ayush Sawal authored
      This patch calculates src and dst sg lengths separately for
      dma mapping in case of aead operation.
      
      This fixes a panic which occurs due to the accessing of a zero
      length sg.
      Panic:
      [  138.173225] kernel BUG at drivers/iommu/intel-iommu.c:1184!
      Signed-off-by: default avatarAyush Sawal <ayush.sawal@chelsio.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb90a1c8
  3. 10 Jun, 2020 7 commits
    • Jakub Kicinski's avatar
      docs: networkng: fix lists and table in sja1105 · 934e36ec
      Jakub Kicinski authored
      We need an empty line before list stats, otherwise first point
      will be smooshed into the paragraph. Inside tables text must
      start at the same offset in the cell, otherwise sphinx thinks
      it's a new indented block.
      
      Documentation/networking/dsa/sja1105.rst:108: WARNING: Block quote ends without a blank line; unexpected unindent.
      Documentation/networking/dsa/sja1105.rst:112: WARNING: Definition list ends without a blank line; unexpected unindent.
      Documentation/networking/dsa/sja1105.rst:245: WARNING: Unexpected indentation.
      Documentation/networking/dsa/sja1105.rst:246: WARNING: Block quote ends without a blank line; unexpected unindent.
      Documentation/networking/dsa/sja1105.rst:253: WARNING: Unexpected indentation.
      Documentation/networking/dsa/sja1105.rst:254: WARNING: Block quote ends without a blank line; unexpected unindent.
      
      Fixes: a20bc43b ("docs: net: dsa: sja1105: document the best_effort_vlan_filtering option")
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Acked-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      934e36ec
    • Jakub Kicinski's avatar
      docs: networking: fix extra spaces in ethtool-netlink · 58e898a0
      Jakub Kicinski authored
      Sphinx appears to get upset at extra spaces at the end of a literal:
      
      Documentation/networking/ethtool-netlink.rst:1032: WARNING: Inline literal start-string without end-string.
      Documentation/networking/ethtool-netlink.rst:1034: WARNING: Inline literal start-string without end-string.
      Documentation/networking/ethtool-netlink.rst:1036: WARNING: Inline literal start-string without end-string.
      Documentation/networking/ethtool-netlink.rst:1089: WARNING: Inline literal start-string without end-string.
      Documentation/networking/ethtool-netlink.rst:1091: WARNING: Inline literal start-string without end-string.
      Documentation/networking/ethtool-netlink.rst:1093: WARNING: Inline literal start-string without end-string.
      
      Fixes: f2bc8ad3 ("net: ethtool: Allow PHY cable test TDR data to configured")
      Fixes: a331172b ("net: ethtool: Add attributes for cable test TDR data")
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58e898a0
    • Corentin Labbe's avatar
      net: cadence: macb: disable NAPI on error · 014406ba
      Corentin Labbe authored
      When the PHY is not working, the macb driver crash on a second try to
      setup it.
      [   78.545994] macb e000b000.ethernet eth0: Could not attach PHY (-19)
      ifconfig: SIOCSIFFLAGS: No such device
      [   78.655457] ------------[ cut here ]------------
      [   78.656014] kernel BUG at /linux-next/include/linux/netdevice.h:521!
      [   78.656504] Internal error: Oops - BUG: 0 [#1] SMP ARM
      [   78.657079] Modules linked in:
      [   78.657795] CPU: 0 PID: 122 Comm: ifconfig Not tainted 5.7.0-next-20200609 #1
      [   78.658202] Hardware name: Xilinx Zynq Platform
      [   78.659632] PC is at macb_open+0x220/0x294
      [   78.660160] LR is at 0x0
      [   78.660373] pc : [<c0b0a634>]    lr : [<00000000>]    psr: 60000013
      [   78.660716] sp : c89ffd70  ip : c8a28800  fp : c199bac0
      [   78.661040] r10: 00000000  r9 : c8838540  r8 : c8838568
      [   78.661362] r7 : 00000001  r6 : c8838000  r5 : c883c000  r4 : 00000000
      [   78.661724] r3 : 00000010  r2 : 00000000  r1 : 00000000  r0 : 00000000
      [   78.662187] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      [   78.662635] Control: 10c5387d  Table: 08b64059  DAC: 00000051
      [   78.663035] Process ifconfig (pid: 122, stack limit = 0x(ptrval))
      [   78.663476] Stack: (0xc89ffd70 to 0xc8a00000)
      [   78.664121] fd60:                                     00000000 c89fe000 c8838000 c89fe000
      [   78.664866] fd80: 00000000 c11ff9ac c8838028 00000000 00000000 c0de6f2c 00000001 c1804eec
      [   78.665579] fda0: c19b8178 c8838000 00000000 ca760866 c8838000 00000001 00001043 c89fe000
      [   78.666355] fdc0: 00001002 c0de72f4 c89fe000 c0de8dc0 00008914 c89fe000 c199bac0 ca760866
      [   78.667111] fde0: c89ffddc c8838000 00001002 00000000 c8838138 c881010c 00008914 c0de7364
      [   78.667862] fe00: 00000000 c89ffe70 c89fe000 ffffffff c881010c c0e8bd48 00000003 00000000
      [   78.668601] fe20: c8838000 c8810100 39c1118f 00039c11 c89a0960 00001043 00000000 000a26d0
      [   78.669343] fe40: b6f43000 ca760866 c89a0960 00000051 befe6c50 00008914 c8b2a3c0 befe6c50
      [   78.670086] fe60: 00000003 ee610500 00000000 c0e8ef58 30687465 00000000 00000000 00000000
      [   78.670865] fe80: 00001043 00000000 000a26d0 b6f43000 c89a0600 ee40ae7c c8870d00 c0ddabf4
      [   78.671593] fea0: c89ffeec c0ddabf4 c89ffeec c199bac0 00008913 c0ddac48 c89ffeec c89fe000
      [   78.672324] fec0: befe6c50 ca760866 befe6c50 00008914 c89fe000 befe6c50 c8b2a3c0 c0dc00e4
      [   78.673088] fee0: c89a0480 00000201 00000cc0 30687465 00000000 00000000 00000000 00001002
      [   78.673822] ff00: 00000000 000a26d0 b6f43000 ca760866 00008914 c8b2a3c0 000a0ec4 c8b2a3c0
      [   78.674576] ff20: befe6c50 c04b21bc 000d5004 00000817 c89a0480 c0315f94 00000000 00000003
      [   78.675415] ff40: c19a2bc8 c8a3cc00 c89fe000 00000255 00000000 00000000 00000000 000d5000
      [   78.676182] ff60: 000f6000 c180b2a0 00000817 c0315e64 000d5004 c89fffb0 b6ec0c30 ca760866
      [   78.676928] ff80: 00000000 000b609b befe6c50 000a0ec4 00000036 c03002c4 c89fe000 00000036
      [   78.677673] ffa0: 00000000 c03000c0 000b609b befe6c50 00000003 00008914 befe6c50 000b609b
      [   78.678415] ffc0: 000b609b befe6c50 000a0ec4 00000036 befe6e0c befe6f1a 000d5150 00000000
      [   78.679154] ffe0: 000d41e4 befe6bf4 00019648 b6e4509c 20000010 00000003 00000000 00000000
      [   78.681059] [<c0b0a634>] (macb_open) from [<c0de6f2c>] (__dev_open+0xd0/0x154)
      [   78.681571] [<c0de6f2c>] (__dev_open) from [<c0de72f4>] (__dev_change_flags+0x16c/0x1c4)
      [   78.682015] [<c0de72f4>] (__dev_change_flags) from [<c0de7364>] (dev_change_flags+0x18/0x48)
      [   78.682493] [<c0de7364>] (dev_change_flags) from [<c0e8bd48>] (devinet_ioctl+0x5e4/0x75c)
      [   78.682945] [<c0e8bd48>] (devinet_ioctl) from [<c0e8ef58>] (inet_ioctl+0x1f0/0x3b4)
      [   78.683381] [<c0e8ef58>] (inet_ioctl) from [<c0dc00e4>] (sock_ioctl+0x39c/0x664)
      [   78.683818] [<c0dc00e4>] (sock_ioctl) from [<c04b21bc>] (ksys_ioctl+0x2d8/0x9c0)
      [   78.684343] [<c04b21bc>] (ksys_ioctl) from [<c03000c0>] (ret_fast_syscall+0x0/0x54)
      [   78.684789] Exception stack(0xc89fffa8 to 0xc89ffff0)
      [   78.685346] ffa0:                   000b609b befe6c50 00000003 00008914 befe6c50 000b609b
      [   78.686106] ffc0: 000b609b befe6c50 000a0ec4 00000036 befe6e0c befe6f1a 000d5150 00000000
      [   78.686710] ffe0: 000d41e4 befe6bf4 00019648 b6e4509c
      [   78.687582] Code: 9a000003 e5983078 e3130001 1affffef (e7f001f2)
      [   78.688788] ---[ end trace e3f2f6ab69754eae ]---
      
      This is due to NAPI left enabled if macb_phylink_connect() fail.
      
      Fixes: 7897b071 ("net: macb: convert to phylink")
      Signed-off-by: default avatarCorentin Labbe <clabbe@baylibre.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      014406ba
    • Paolo Abeni's avatar
      mptcp: don't leak msk in token container · 4b5af441
      Paolo Abeni authored
      If a listening MPTCP socket has unaccepted sockets at close
      time, the related msks are freed via mptcp_sock_destruct(),
      which in turn does not invoke the proto->destroy() method
      nor the mptcp_token_destroy() function.
      
      Due to the above, the child msk socket is not removed from
      the token container, leading to later UaF.
      
      Address the issue explicitly removing the token even in the
      above error path.
      
      Fixes: 79c0949e ("mptcp: Add key generation and token tree")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b5af441
    • Paolo Abeni's avatar
      mptcp: fix races between shutdown and recvmsg · 5969856a
      Paolo Abeni authored
      The msk sk_shutdown flag is set by a workqueue, possibly
      introducing some delay in user-space notification. If the last
      subflow carries some data with the fin packet, the user space
      can wake-up before RCV_SHUTDOWN is set. If it executes unblocking
      recvmsg(), it may return with an error instead of eof.
      
      Address the issue explicitly checking for eof in recvmsg(), when
      no data is found.
      
      Fixes: 59832e24 ("mptcp: subflow: check parent mptcp socket on subflow state change")
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: default avatarMatthieu Baerts <matthieu.baerts@tessares.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5969856a
    • David Ahern's avatar
      vxlan: Remove access to nexthop group struct · 50cb8769
      David Ahern authored
      vxlan driver should be using helpers to access nexthop struct
      internals. Remove open check if whether nexthop is multipath in
      favor of the existing nexthop_is_multipath helper. Add a new
      helper, nexthop_has_v4, to cover the need to check has_v4 in
      a group.
      
      Fixes: 1274e1cc ("vxlan: ecmp support for mac fdb entries")
      Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      50cb8769
    • David Ahern's avatar
      nexthop: Fix fdb labeling for groups · ce9ac056
      David Ahern authored
      fdb nexthops are marked with a flag. For standalone nexthops, a flag was
      added to the nh_info struct. For groups that flag was added to struct
      nexthop when it should have been added to the group information. Fix
      by removing the flag from the nexthop struct and adding a flag to nh_group
      that mirrors nh_info and is really only a caching of the individual types.
      Add a helper, nexthop_is_fdb, for use by the vxlan code and fixup the
      internal code to use the flag from either nh_info or nh_group.
      
      v2
      - propagate fdb_nh in remove_nh_grp_entry
      
      Fixes: 38428d68 ("nexthop: support for fdb ecmp nexthops")
      Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce9ac056
  4. 09 Jun, 2020 2 commits