1. 19 Sep, 2018 3 commits
    • Johannes Berg's avatar
      netlink: add ethernet address policy types · b60b87fc
      Johannes Berg authored
      Commonly, ethernet addresses are just using a policy of
      	{ .len = ETH_ALEN }
      which leaves userspace free to send more data than it should,
      which may hide bugs.
      
      Introduce NLA_EXACT_LEN which checks for exact size, rejecting
      the attribute if it's not exactly that length. Also add
      NLA_EXACT_LEN_WARN which requires the minimum length and will
      warn on longer attributes, for backward compatibility.
      
      Use these to define NLA_POLICY_ETH_ADDR (new strict policy) and
      NLA_POLICY_ETH_ADDR_COMPAT (compatible policy with warning);
      these are used like this:
      
          static const struct nla_policy <name>[...] = {
              [NL_ATTR_NAME] = NLA_POLICY_ETH_ADDR,
              ...
          };
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Reviewed-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b60b87fc
    • Johannes Berg's avatar
      netlink: add NLA_REJECT policy type · 568b742a
      Johannes Berg authored
      In some situations some netlink attributes may be used for output
      only (kernel->userspace) or may be reserved for future use. It's
      then helpful to be able to prevent userspace from using them in
      messages sent to the kernel, since they'd otherwise be ignored and
      any future will become impossible if this happens.
      
      Add NLA_REJECT to the policy which does nothing but reject (with
      EINVAL) validation of any messages containing this attribute.
      Allow for returning a specific extended ACK error message in the
      validation_data pointer.
      
      While at it clear up the documentation a bit - the NLA_BITFIELD32
      documentation was added to the list of len field descriptions.
      
      Also, use NL_SET_BAD_ATTR() in one place where it's open-coded.
      
      The specific case I have in mind now is a shared nested attribute
      containing request/response data, and it would be pointless and
      potentially confusing to have userspace include response data in
      the messages that actually contain a request.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Reviewed-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      568b742a
    • David S. Miller's avatar
      Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue · 89f4b9a6
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      40GbE Intel Wired LAN Driver Updates 2018-09-18
      
      This series contains changes to i40evf so that it becomes a more
      generic virtual function driver for current and future silicon.
      
      While doing the rename of i40evf to a more generic name of iavf,
      we also put the driver on a severe diet due to how much of the
      code was unneeded or was unused.  The outcome is a lean and mean
      virtual function driver that continues to work on existing 40GbE
      (i40e) virtual devices and prepped for future supported devices,
      like the 100GbE (ice) virtual devices.
      
      This solves 2 issues we saw coming or were already present, the
      first was constant code duplication happening with i40e/i40evf,
      when much of the duplicate code in the i40evf was not used or was
      not needed.  The second was to remove the future confusion of why
      future VF devices that were not considered "40GbE" only devices
      were supported by i40evf.
      
      The thought is that iavf will be the virtual function driver for
      all future devices, so it should have a "generic" name to properly
      represent that it is the VF driver for multiple generations of
      devices.
      
      The last patch in this series is unreleated to the iavf conversion
      and just has to do with a MODULE_LICENSE correction.
      
      Known Caveats:
      Existing user space configurations may have to change, but the module
      alias in patch 1 helps a bit here.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89f4b9a6
  2. 18 Sep, 2018 34 commits
  3. 17 Sep, 2018 3 commits