Skip to content
  1. Sep 04, 2019
  2. Sep 02, 2019
  3. Sep 01, 2019
    • Ben Wei's avatar
      net/ncsi: add response handlers for PLDM over NC-SI · 6f671045
      Ben Wei authored
      
      
      This patch adds handlers for PLDM over NC-SI command response.
      
      This enables NC-SI driver recognizes the packet type so the responses
      don't get dropped as unknown packet type.
      
      PLDM over NC-SI are not handled in kernel driver for now, but can be
      passed back to user space via Netlink for further handling.
      
      Signed-off-by: default avatarBen Wei <benwei@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f671045
    • David S. Miller's avatar
      Merge branch 'Minor-cleanup-in-devlink' · 38320f69
      David S. Miller authored
      
      
      Parav Pandit says:
      
      ====================
      Minor cleanup in devlink
      
      Two minor cleanup in devlink.
      
      Patch-1 Explicitly defines devlink port index as unsigned int
      Patch-2 Uses switch-case to handle different port flavours attributes
      ====================
      
      Acked-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      38320f69
    • Parav Pandit's avatar
      devlink: Use switch-case instead of if-else · 58b6be41
      Parav Pandit authored
      
      
      Make core more readable with switch-case for various port flavours.
      
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarParav Pandit <parav@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58b6be41
    • Parav Pandit's avatar
      devlink: Make port index data type as unsigned int · c7282b50
      Parav Pandit authored
      
      
      Devlink port index attribute is returned to users as u32 through
      netlink response.
      Change index data type from 'unsigned' to 'unsigned int' to avoid
      below checkpatch.pl warning.
      
      WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
      81: FILE: include/net/devlink.h:81:
      +       unsigned index;
      
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarParav Pandit <parav@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7282b50
    • David S. Miller's avatar
      Merge branch 'net-tls-add-socket-diag' · 1b6ca07b
      David S. Miller authored
      
      
      Davide Caratti says:
      
      ====================
      net: tls: add socket diag
      
      The current kernel does not provide any diagnostic tool, except
      getsockopt(TCP_ULP), to know more about TCP sockets that have an upper
      layer protocol (ULP) on top of them. This series extends the set of
      information exported by INET_DIAG_INFO, to include data that are
      specific to the ULP (and that might be meaningful for debug/testing
      purposes).
      
      patch 1/3 ensures that the control plane reads/updates ULP specific data
      using RCU.
      
      patch 2/3 extends INET_DIAG_INFO and allows knowing the ULP name for
      each TCP socket that has done setsockopt(TCP_ULP) successfully.
      
      patch 3/3 extends kTLS to let programs like 'ss' know the protocol
      version and the cipher in use.
      
      Changes since v2:
      - remove unneeded #ifdef and fix reverse christmas tree in
        tls_get_info(), thanks to Jakub Kicinski
      
      Changes since v1:
      - don't worry about grace period when accessing ulp_ops, thanks to
        Jakub Kicinski and Eric Dumazet
      - use rcu_dereference() to access ULP data in tls get_info(), and
        test against NULL value, thanks to Jakub Kicinski
      - move RCU protected section inside tls get_info(), thanks to Jakub
        Kicinski
      
      Changes since RFC:
      - some coding style fixes, thanks to Jakub Kicinski
      - add X_UNSPEC as lowest value of uAPI enums, thanks to Jakub Kicinski
      - fix assignment of struct nlattr *start, thanks to Jakub Kicinski
      - let tls dump RXCONF and TXCONF, suggested by Jakub Kicinski
      - don't dump anything if TLS version or cipher are 0 (but still return a
        constant size in get_aux_size()), thanks to Boris Pismenny
      - constify first argument of get_info() and get_size()
      - use RCU to access access ulp_ops, like it's done for ca_ops
      - add patch 1/3, from Jakub Kicinski
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1b6ca07b
    • Davide Caratti's avatar
      net: tls: export protocol version, cipher, tx_conf/rx_conf to socket diag · 26811cc9
      Davide Caratti authored
      
      
      When an application configures kernel TLS on top of a TCP socket, it's
      now possible for inet_diag_handler() to collect information regarding the
      protocol version, the cipher type and TX / RX configuration, in case
      INET_DIAG_INFO is requested.
      
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26811cc9
    • Davide Caratti's avatar
      tcp: ulp: add functions to dump ulp-specific information · 61723b39
      Davide Caratti authored
      
      
      currently, only getsockopt(TCP_ULP) can be invoked to know if a ULP is on
      top of a TCP socket. Extend idiag_get_aux() and idiag_get_aux_size(),
      introduced by commit b37e8840 ("inet_diag: allow protocols to provide
      additional data"), to report the ULP name and other information that can
      be made available by the ULP through optional functions.
      
      Users having CAP_NET_ADMIN privileges will then be able to retrieve this
      information through inet_diag_handler, if they specify INET_DIAG_INFO in
      the request.
      
      Signed-off-by: default avatarDavide Caratti <dcaratti@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61723b39
    • Jakub Kicinski's avatar
      net/tls: use RCU protection on icsk->icsk_ulp_data · 15a7dea7
      Jakub Kicinski authored
      
      
      We need to make sure context does not get freed while diag
      code is interrogating it. Free struct tls_context with
      kfree_rcu().
      
      We add the __rcu annotation directly in icsk, and cast it
      away in the datapath accessor. Presumably all ULPs will
      do a similar thing.
      
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      15a7dea7
    • David S. Miller's avatar
      Merge branch 'qed-Enhancements' · ed6e8103
      David S. Miller authored
      
      
      Sudarsana Reddy Kalluru says:
      
      ====================
      qed*: Enhancements.
      
      The patch series adds couple of enhancements to qed/qede drivers.
        - Support for dumping the config id attributes via ethtool -w/W.
        - Support for dumping the GRC data of required memory regions using
          ethtool -w/W interfaces.
      
      Patch (1) adds driver APIs for reading the config id attributes.
      Patch (2) adds ethtool support for dumping the config id attributes.
      Patch (3) adds support for configuring the GRC dump config flags.
      Patch (4) adds ethtool support for dumping the grc dump.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ed6e8103
    • Sudarsana Reddy Kalluru's avatar
      qede: Add support for dumping the grc data. · 849dbf09
      Sudarsana Reddy Kalluru authored
      
      
      This patch adds driver support for configuring grc dump config flags, and
      dumping the grc data via ethtool get/set-dump interfaces.
      
      Signed-off-by: default avatarSudarsana Reddy Kalluru <skalluru@marvell.com>
      Signed-off-by: default avatarAriel Elior <aelior@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      849dbf09
    • Sudarsana Reddy Kalluru's avatar
      qed: Add APIs for configuring grc dump config flags. · 3b86bd07
      Sudarsana Reddy Kalluru authored
      
      
      The patch adds driver support for configuring the grc dump config flags.
      
      Signed-off-by: default avatarSudarsana Reddy Kalluru <skalluru@marvell.com>
      Signed-off-by: default avatarAriel Elior <aelior@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b86bd07
    • Sudarsana Reddy Kalluru's avatar
      qede: Add support for reading the config id attributes. · d44a3ced
      Sudarsana Reddy Kalluru authored
      
      
      Add driver support for dumping the config id attributes via ethtool dump
      interfaces.
      
      Signed-off-by: default avatarSudarsana Reddy Kalluru <skalluru@marvell.com>
      Signed-off-by: default avatarAriel Elior <aelior@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d44a3ced
    • Sudarsana Reddy Kalluru's avatar
      qed: Add APIs for reading config id attributes. · 2d4c8495
      Sudarsana Reddy Kalluru authored
      
      
      The patch adds driver support for reading the config id attributes from NVM
      flash partition.
      
      Signed-off-by: default avatarSudarsana Reddy Kalluru <skalluru@marvell.com>
      Signed-off-by: default avatarAriel Elior <aelior@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2d4c8495
    • David S. Miller's avatar
      Merge branch 'Dynamic-toggling-of-vlan_filtering-for-SJA1105-DSA' · b0274eb0
      David S. Miller authored
      
      
      Vladimir Oltean says:
      
      ====================
      Dynamic toggling of vlan_filtering for SJA1105 DSA
      
      This patchset addresses a limitation in dsa_8021q where this sequence of
      commands was causing the switch to stop forwarding traffic:
      
        ip link add name br0 type bridge vlan_filtering 0
        ip link set dev swp2 master br0
        echo 1 > /sys/class/net/br0/bridge/vlan_filtering
        echo 0 > /sys/class/net/br0/bridge/vlan_filtering
      
      The issue has to do with the VLAN table manipulations that dsa_8021q
      does without notifying the bridge layer. The solution is to always
      restore the VLANs that the bridge knows about, when disabling tagging.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b0274eb0
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: Restore bridge VLANs when enabling vlan_filtering · 5f33183b
      Vladimir Oltean authored
      
      
      The bridge core assumes that enabling/disabling vlan_filtering will
      translate into the simple toggling of a flag for switchdev drivers.
      
      That is clearly not the case for sja1105, which alters the VLAN table
      and the pvids in order to obtain port separation in standalone mode.
      
      There are 2 parts to the issue.
      
      First, tag_8021q changes the pvid to a unique per-port rx_vid for frame
      identification. But we need to disable tag_8021q when vlan_filtering
      kicks in, and at that point, the VLAN configured as pvid will have to be
      removed from the filtering table of the ports. With an invalid pvid, the
      ports will drop all traffic.  Since the bridge will not call any vlan
      operation through switchdev after enabling vlan_filtering, we need to
      ensure we're in a functional state ourselves. Hence read the pvid that
      the bridge is aware of, and program that into our ports.
      
      Secondly, tag_8021q uses the 1024-3071 range privately in
      vlan_filtering=0 mode. Had the user installed one of these VLANs during
      a previous vlan_filtering=1 session, then upon the next tag_8021q
      cleanup for vlan_filtering to kick in again, VLANs in that range will
      get deleted unconditionally, hence breaking user expectation. So when
      deleting the VLANs, check if the bridge had knowledge about them, and if
      it did, re-apply the settings. Wrap this logic inside a
      dsa_8021q_vid_apply helper function to reduce code duplication.
      
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f33183b
    • Vladimir Oltean's avatar
      net: bridge: Populate the pvid flag in br_vlan_get_info · f40d9b20
      Vladimir Oltean authored
      
      
      Currently this simplified code snippet fails:
      
      	br_vlan_get_pvid(netdev, &pvid);
      	br_vlan_get_info(netdev, pvid, &vinfo);
      	ASSERT(!(vinfo.flags & BRIDGE_VLAN_INFO_PVID));
      
      It is intuitive that the pvid of a netdevice should have the
      BRIDGE_VLAN_INFO_PVID flag set.
      
      However I can't seem to pinpoint a commit where this behavior was
      introduced. It seems like it's been like that since forever.
      
      At a first glance it would make more sense to just handle the
      BRIDGE_VLAN_INFO_PVID flag in __vlan_add_flags. However, as Nikolay
      explains:
      
        There are a few reasons why we don't do it, most importantly because
        we need to have only one visible pvid at any single time, even if it's
        stale - it must be just one. Right now that rule will not be violated
        by this change, but people will try using this flag and could see two
        pvids simultaneously. You can see that the pvid code is even using
        memory barriers to propagate the new value faster and everywhere the
        pvid is read only once.  That is the reason the flag is set
        dynamically when dumping entries, too.  A second (weaker) argument
        against would be given the above we don't want another way to do the
        same thing, specifically if it can provide us with two pvids (e.g. if
        walking the vlan list) or if it can provide us with a pvid different
        from the one set in the vg. [Obviously, I'm talking about RCU
        pvid/vlan use cases similar to the dumps.  The locked cases are fine.
        I would like to avoid explaining why this shouldn't be relied upon
        without locking]
      
      So instead of introducing the above change and making sure of the pvid
      uniqueness under RCU, simply dynamically populate the pvid flag in
      br_vlan_get_info().
      
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f40d9b20