1. 02 Mar, 2020 20 commits
  2. 01 Mar, 2020 20 commits
    • Gustavo A. R. Silva's avatar
      arcnet: Replace zero-length array with flexible-array member · 5a8b7c4b
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a8b7c4b
    • Gustavo A. R. Silva's avatar
      neighbour: Replace zero-length array with flexible-array member · 08ca27d0
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      08ca27d0
    • Gustavo A. R. Silva's avatar
      net: flow_offload: Replace zero-length array with flexible-array member · 8661b6e7
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8661b6e7
    • Gustavo A. R. Silva's avatar
      net: dn_fib: Replace zero-length array with flexible-array member · a79b41ec
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a79b41ec
    • Gustavo A. R. Silva's avatar
      ndisc: Replace zero-length array with flexible-array member · 53e76f48
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      53e76f48
    • Gustavo A. R. Silva's avatar
      net: ipv6: mld: Replace zero-length array with flexible-array member · c61a2a76
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c61a2a76
    • Gustavo A. R. Silva's avatar
      net: lwtunnel: Replace zero-length array with flexible-array member · e8316026
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8316026
    • Gustavo A. R. Silva's avatar
      net: ip6_route: Replace zero-length array with flexible-array member · 207644f5
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      207644f5
    • Gustavo A. R. Silva's avatar
      net: nexthop: Replace zero-length array with flexible-array member · 97a888c2
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Reviewed-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97a888c2
    • Gustavo A. R. Silva's avatar
      net: sctp: Replace zero-length array with flexible-array member · 2e7aaaa1
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e7aaaa1
    • Gustavo A. R. Silva's avatar
      net: sock_reuseport: Replace zero-length array with flexible-array member · 2603c29e
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2603c29e
    • David S. Miller's avatar
      Merge branch 'net-ethtool-Introduce-link_ksettings-API-for-virtual-network-devices' · de301810
      David S. Miller authored
      Cris Forno says:
      
      ====================
      net/ethtool: Introduce link_ksettings API for virtual network devices
      
      This series provides an API for drivers of virtual network devices that
      allows users to alter initial device speed and duplex settings to reflect
      the actual capabilities of underlying hardware. The changes made include
      a helper function ethtool_virtdev_set_link_ksettings, which is used to
      retrieve alterable link settings. In addition, there is a new ethtool
      function defined to validate those settings. These changes resolve code
      duplication for existing virtual network drivers that have already
      implemented this behavior.  In the case of the ibmveth driver, this API is
      used to provide this capability for the first time.
      
      ---
      v7:  - removed ethtool_validate_cmd function pointer parameter from
            ethtool_virtdev_set_link_ksettings since none of the virtual drivers
            pass in a custom validate function as suggested by Michal Kubecek.
      
      v6:  - removed netvsc_validate_ethtool_ss_cmd(). netvsc_drv now uses
           ethtool_virtdev_validate_cmd() instead as suggested by Michal Kubecek
           and approved by Haiyang Zhang.
      
           - matched handler argument name of ethtool_virtdev_set_link_ksettings
           in declaration and definition as suggested by Michal Kubecek.
      
           - shortened validate variable assignment in
           ethtool_virtdev_set_link_ksettings as suggested by Michal Kubecek.
      
      v5:  - virtdev_validate_link_ksettings is taken out of the ethtool global
           structure and is instead added as an argument to
           ethtool_virtdev_set_link_ksettings as suggested by Jakub Kicinski.
      
      v4:  - Cleaned up return statement in ethtool_virtdev_validate_cmd based
           off of Michal Kubecek's and Thomas Falcon's suggestion.
      
           - If the netvsc driver is using the VF device in order to get
           accelerated networking, the real speed and duplex is reported by using
           the VF device as suggested by Stephen Hemminger.
      
           - The speed and duplex variables are now passed by value rather than
           passed by pointer as suggested by Willem de Bruijin and Michal
           Kubecek.
      
           - Removed ethtool_virtdev_get_link_ksettings since it was too simple
           to warrant a helper function.
      
      v3:  - Factored out duplicated code to core/ethtool to provide API to
           virtual drivers
      
      v2:  - Updated default driver speed/duplex settings to avoid breaking
           existing setups
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      de301810
    • Cris Forno's avatar
      net/ethtool: Introduce link_ksettings API for virtual network devices · 9aedc6e2
      Cris Forno authored
      With the ethtool_virtdev_set_link_ksettings function in core/ethtool.c,
      ibmveth, netvsc, and virtio now use the core's helper function.
      
      Funtionality changes that pertain to ibmveth driver include:
      
        1. Changed the initial hardcoded link speed to 1GB.
      
        2. Added support for allowing a user to change the reported link
        speed via ethtool.
      
      Functionality changes to the netvsc driver include:
      
        1. When netvsc_get_link_ksettings is called, it will defer to the VF
        device if it exists to pull accelerated networking values, otherwise
        pull default or user-defined values.
      
        2. Similarly, if netvsc_set_link_ksettings called and a VF device
        exists, the real values of speed and duplex are changed.
      Signed-off-by: default avatarCris Forno <cforno12@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9aedc6e2
    • Cris Forno's avatar
      ethtool: Factored out similar ethtool link settings for virtual devices to core · 70ae1e12
      Cris Forno authored
      Three virtual devices (ibmveth, virtio_net, and netvsc) all have
      similar code to set link settings and validate ethtool command. To
      eliminate duplication of code, it is factored out into core/ethtool.c.
      Signed-off-by: default avatarCris Forno <cforno12@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      70ae1e12
    • David S. Miller's avatar
      Merge branch 'hsr-several-code-cleanup-for-hsr-module' · 68e2c376
      David S. Miller authored
      Taehee Yoo says:
      
      ====================
      hsr: several code cleanup for hsr module
      
      This patchset is to clean up hsr module code.
      
      1. The first patch is to use debugfs_remove_recursive().
      If it uses debugfs_remove_recursive() instead of debugfs_remove(),
      hsr_priv() doesn't need to have "node_tbl_file" pointer variable.
      
      2. The second patch is to use extack error message.
      If HSR uses the extack instead of netdev_info(), users can get
      error messages immediately without any checking the kernel message.
      
      3. The third patch is to use netdev_err() instead of WARN_ONCE().
      When a packet is being sent, hsr_addr_subst_dest() is called and
      it tries to find the node with the ethernet destination address.
      If it couldn't find a node, it warns with WARN_ONCE().
      But, using WARN_ONCE() is a little bit overdoing.
      So, in this patch, netdev_err() is used instead.
      
      4. The fourth patch is to remove unnecessary rcu_read_{lock/unlock}().
      There are some rcu_read_{lock/unlock}() in hsr module and some of
      them are unnecessary. In this patch,
      these unnecessary rcu_read_{lock/unlock}() will be removed.
      
      5. The fifth patch is to use upper/lower device infrastructure.
      netdev_upper_dev_link() is useful to manage lower/upper interfaces.
      And this function internally validates looping, maximum depth.
      If hsr module uses upper/lower device infrastructure,
      it can prevent these above problems.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68e2c376
    • Taehee Yoo's avatar
      hsr: use upper/lower device infrastructure · e0a4b997
      Taehee Yoo authored
      netdev_upper_dev_link() is useful to manage lower/upper interfaces.
      And this function internally validates looping, maximum depth.
      All or most virtual interfaces that could have a real interface
      (e.g. macsec, macvlan, ipvlan etc.) use lower/upper infrastructure.
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0a4b997
    • Taehee Yoo's avatar
      hsr: remove unnecessary rcu_read_lock() in hsr module · 81390d0c
      Taehee Yoo authored
      In order to access the port list, the hsr_port_get_hsr() is used.
      And this is protected by RTNL and RCU.
      The hsr_fill_info(), hsr_check_carrier(), hsr_dev_open() and
      hsr_get_max_mtu() are protected by RTNL.
      So, rcu_read_lock() in these functions are not necessary.
      The hsr_handle_frame() also uses rcu_read_lock() but this function
      is called by packet path.
      It's already protected by RCU.
      So, the rcu_read_lock() in hsr_handle_frame() can be removed.
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      81390d0c
    • Taehee Yoo's avatar
      hsr: use netdev_err() instead of WARN_ONCE() · 4b793acd
      Taehee Yoo authored
      When HSR interface is sending a frame, it finds a node with
      the destination ethernet address from the list.
      If there is no node, it calls WARN_ONCE().
      But, using WARN_ONCE() for this situation is a little bit overdoing.
      So, in this patch, the netdev_err() is used instead.
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4b793acd
    • Taehee Yoo's avatar
      hsr: use extack error message instead of netdev_info · 13eeb5fe
      Taehee Yoo authored
      If HSR uses the extack instead of netdev_info(), users can get
      error messages immediately without any checking the kernel message.
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      13eeb5fe
    • Taehee Yoo's avatar
      hsr: use debugfs_remove_recursive() instead of debugfs_remove() · f3f2f984
      Taehee Yoo authored
      If it uses debugfs_remove_recursive() instead of debugfs_remove(),
      hsr_priv() doesn't need to have "node_tbl_file" pointer variable.
      Signed-off-by: default avatarTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f3f2f984