1. 23 Jul, 2020 13 commits
    • Tom Parkin's avatar
      l2tp: cleanup suspect code indent · 0864e331
      Tom Parkin authored
      l2tp_core has conditionally compiled code in l2tp_xmit_skb for IPv6
      support.  The structure of this code triggered a checkpatch warning
      due to incorrect indentation.
      
      Fix up the indentation to address the checkpatch warning.
      Signed-off-by: default avatarTom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0864e331
    • Tom Parkin's avatar
      l2tp: cleanup wonky alignment of line-broken function calls · 8ce9825a
      Tom Parkin authored
      Arguments should be aligned with the function call open parenthesis as
      per checkpatch.  Tweak some function calls which were not aligned
      correctly.
      Signed-off-by: default avatarTom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ce9825a
    • Tom Parkin's avatar
      l2tp: cleanup difficult-to-read line breaks · 9f7da9a0
      Tom Parkin authored
      Some l2tp code had line breaks which made the code more difficult to
      read.  These were originally motivated by the 80-character line width
      coding guidelines, but were actually a negative from the perspective of
      trying to follow the code.
      
      Remove these linebreaks for clearer code, even if we do exceed 80
      characters in width in some places.
      Signed-off-by: default avatarTom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f7da9a0
    • Tom Parkin's avatar
      l2tp: cleanup comments · 20dcb110
      Tom Parkin authored
      Modify some l2tp comments to better adhere to kernel coding style, as
      reported by checkpatch.pl.
      
      Add descriptive comments for the l2tp per-net spinlocks to document
      their use.
      
      Fix an incorrect comment in l2tp_recv_common:
      
      RFC2661 section 5.4 states that:
      
      "The LNS controls enabling and disabling of sequence numbers by sending a
      data message with or without sequence numbers present at any time during
      the life of a session."
      
      l2tp handles this correctly in l2tp_recv_common, but the comment around
      the code was incorrect and confusing.  Fix up the comment accordingly.
      Signed-off-by: default avatarTom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20dcb110
    • Tom Parkin's avatar
      l2tp: cleanup whitespace use · b71a61cc
      Tom Parkin authored
      Fix up various whitespace issues as reported by checkpatch.pl:
      
       * remove spaces around operators where appropriate,
       * add missing blank lines following declarations,
       * remove multiple blank lines, or trailing blank lines at the end of
         functions.
      Signed-off-by: default avatarTom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b71a61cc
    • Parav Pandit's avatar
      devlink: Always use user_ptr[0] for devlink and simplify post_doit · 637989b5
      Parav Pandit authored
      Currently devlink instance is searched on all doit() operations.
      But it is optionally stored into user_ptr[0]. This requires
      rediscovering devlink again doing post_doit().
      
      Few devlink commands related to port shared buffers needs 3 pointers
      (devlink, devlink_port, and devlink_sb) while executing doit commands.
      Though devlink pointer can be derived from the devlink_port during
      post_doit() operation when doit() callback has acquired devlink
      instance lock, relying on such scheme to access devlik pointer makes
      code very fragile.
      
      Hence, to avoid ambiguity in post_doit() and to avoid searching
      devlink instance again, simplify code by always storing devlink
      instance in user_ptr[0] and derive devlink_sb pointer in their
      respective callback routines.
      Signed-off-by: default avatarParav Pandit <parav@mellanox.com>
      Reviewed-by: default avatarJiri Pirko <jiri@mellanox.com>
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      637989b5
    • Sriram Krishnan's avatar
      hv_netvsc: add support for vlans in AF_PACKET mode · fdd8fac4
      Sriram Krishnan authored
      Vlan tagged packets are getting dropped when used with DPDK that uses
      the AF_PACKET interface on a hyperV guest.
      
      The packet layer uses the tpacket interface to communicate the vlans
      information to the upper layers. On Rx path, these drivers can read the
      vlan info from the tpacket header but on the Tx path, this information
      is still within the packet frame and requires the paravirtual drivers to
      push this back into the NDIS header which is then used by the host OS to
      form the packet.
      
      This transition from the packet frame to NDIS header is currently missing
      hence causing the host OS to drop the all vlan tagged packets sent by
      the drivers that use AF_PACKET (ETH_P_ALL) such as DPDK.
      
      Here is an overview of the changes in the vlan header in the packet path:
      
      The RX path (userspace handles everything):
        1. RX VLAN packet is stripped by HOST OS and placed in NDIS header
        2. Guest Kernel RX hv_netvsc packets and moves VLAN info from NDIS
           header into kernel SKB
        3. Kernel shares packets with user space application with PACKET_MMAP.
           The SKB VLAN info is copied to tpacket layer and indication set
           TP_STATUS_VLAN_VALID.
        4. The user space application will re-insert the VLAN info into the frame
      
      The TX path:
        1. The user space application has the VLAN info in the frame.
        2. Guest kernel gets packets from the application with PACKET_MMAP.
        3. The kernel later sends the frame to the hv_netvsc driver. The only way
           to send VLANs is when the SKB is setup & the VLAN is stripped from the
           frame.
        4. TX VLAN is re-inserted by HOST OS based on the NDIS header. If it sees
           a VLAN in the frame the packet is dropped.
      
      Cc: xe-linux-external@cisco.com
      Cc: Sriram Krishnan <srirakr2@cisco.com>
      Signed-off-by: default avatarSriram Krishnan <srirakr2@cisco.com>
      Reviewed-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fdd8fac4
    • Paolo Abeni's avatar
      mptcp: zero token hash at creation time. · 6ab301c9
      Paolo Abeni authored
      Otherwise the 'chain_len' filed will carry random values,
      some token creation calls will fail due to excessive chain
      length, causing unexpected fallback to TCP.
      
      Fixes: 2c5ebd00 ("mptcp: refactor token container")
      Reviewed-by: default avatarMat Martineau <mathew.j.martineau@linux.intel.com>
      Tested-by: default avatarChristoph Paasch <cpaasch@apple.com>
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6ab301c9
    • Colin Ian King's avatar
      lan743x: remove redundant initialization of variable current_head_index · bb809a04
      Colin Ian King authored
      The variable current_head_index is being initialized with a value that
      is never read and it is being updated later with a new value.  Replace
      the initialization of -1 with the latter assignment.
      
      Addresses-Coverity: ("Unused value")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bb809a04
    • Claudiu Manoil's avatar
      enetc: Remove the imdio bus on PF probe bailout · c6dd6488
      Claudiu Manoil authored
      enetc_imdio_remove() is missing from the enetc_pf_probe()
      bailout path. Not surprisingly because enetc_setup_serdes()
      is registering the imdio bus for internal purposes, and it's
      not obvious that enetc_imdio_remove() currently performs the
      teardown of enetc_setup_serdes().
      To fix this, define enetc_teardown_serdes() to wrap
      enetc_imdio_remove() (improve code maintenance) and call it
      on bailout and remove paths.
      
      Fixes: 975d183e ("net: enetc: Initialize SerDes for SGMII and USXGMII protocols")
      Signed-off-by: default avatarClaudiu Manoil <claudiu.manoil@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c6dd6488
    • Wang Hai's avatar
      net: qed: Remove unneeded cast from memory allocation · 7979a7d2
      Wang Hai authored
      Remove casting the values returned by memory allocation function.
      
      Coccinelle emits WARNING: casting value returned by memory allocation
      unction to (struct roce_destroy_qp_req_output_params *) is useless.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: default avatarWang Hai <wanghai38@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7979a7d2
    • Vladimir Oltean's avatar
      net: phy: fix check in get_phy_c45_ids · fb16d465
      Vladimir Oltean authored
      After the patch below, the iteration through the available MMDs is
      completely short-circuited, and devs_in_pkg remains set to the initial
      value of zero.
      
      Due to devs_in_pkg being zero, the rest of get_phy_c45_ids() is
      short-circuited too: the following loop never reaches below this point
      either (it executes "continue" for every device in package, failing to
      retrieve PHY ID for any of them):
      
      	/* Now probe Device Identifiers for each device present. */
      	for (i = 1; i < num_ids; i++) {
      		if (!(devs_in_pkg & (1 << i)))
      			continue;
      
      So c45_ids->device_ids remains populated with zeroes. This causes an
      Aquantia AQR412 PHY (same as any C45 PHY would, in fact) to be probed by
      the Generic PHY driver.
      
      The issue seems to be a case of submitting partially committed work (and
      therefore testing something other than was submitted).
      
      The intention of the patch was to delay exiting the loop until one more
      condition is reached (the devs_in_pkg read from hardware is either 0, OR
      mostly f's). So fix the patch to reflect that.
      
      Tested with traffic on a LS1028A-QDS, the PHY is now probed correctly
      using the Aquantia driver. The devs_in_pkg bit field is set to
      0xe000009a, and the MMDs that are present have the following IDs:
      
      [    5.600772] libphy: get_phy_c45_ids: device_ids[1]=0x3a1b662
      [    5.618781] libphy: get_phy_c45_ids: device_ids[3]=0x3a1b662
      [    5.630797] libphy: get_phy_c45_ids: device_ids[4]=0x3a1b662
      [    5.654535] libphy: get_phy_c45_ids: device_ids[7]=0x3a1b662
      [    5.791723] libphy: get_phy_c45_ids: device_ids[29]=0x3a1b662
      [    5.804050] libphy: get_phy_c45_ids: device_ids[30]=0x3a1b662
      [    5.816375] libphy: get_phy_c45_ids: device_ids[31]=0x0
      
      [    7.690237] mscc_felix 0000:00:00.5: PHY [0.5:00] driver [Aquantia AQR412] (irq=POLL)
      [    7.704739] mscc_felix 0000:00:00.5: PHY [0.5:01] driver [Aquantia AQR412] (irq=POLL)
      [    7.718918] mscc_felix 0000:00:00.5: PHY [0.5:02] driver [Aquantia AQR412] (irq=POLL)
      [    7.733044] mscc_felix 0000:00:00.5: PHY [0.5:03] driver [Aquantia AQR412] (irq=POLL)
      
      Fixes: bba238ed ("net: phy: continue searching for C45 MMDs even if first returned ffff:ffff")
      Reported-by: default avatarColin King <colin.king@canonical.com>
      Reported-by: default avatarIoana Ciornei <ioana.ciornei@nxp.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb16d465
    • Richard Sailer's avatar
      net: dccp: Add SIOCOUTQ IOCTL support (send buffer fill) · 749c08f8
      Richard Sailer authored
      This adds support for the SIOCOUTQ IOCTL to get the send buffer fill
      of a DCCP socket, like UDP and TCP sockets already have.
      
      Regarding the used data field: DCCP uses per packet sequence numbers,
      not per byte, so sequence numbers can't be used like in TCP. sk_wmem_queued
      is not used by DCCP and always 0, even in test on highly congested paths.
      Therefore this uses sk_wmem_alloc like in UDP.
      Signed-off-by: default avatarRichard Sailer <richard_siegfried@systemli.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      749c08f8
  2. 22 Jul, 2020 15 commits
  3. 21 Jul, 2020 12 commits