Skip to content

L
linux
Switch branch/tag
  1. 01 Apr, 2019 5 commits
    • David S. Miller's avatar
      Merge branch 'cxgb3-undefined-behaviour-and-use-struct_size' · 3370b588
      David S. Miller authored 
      Gustavo A. R. Silva says:

====================
cxgb3/l2t: Fix undefined behaviour and use struct_size() helper

This patchset aims to fix an undefined behaviour when using a zero-sized
array and, add the use of the struct_size() helper in kvzalloc().

You might consider the first patch in this series for stable.

More details in the commit logs.
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3370b588
    • Gustavo A. R. Silva's avatar
      cxgb3/l2t: Use struct_size() in kvzalloc() · db4863fd
      Gustavo A. R. Silva authored 
      One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct foo {
    int stuff;
    struct boo entry[];
};

size = sizeof(struct foo) + count * sizeof(struct boo);
instance = kvzalloc(size, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:

instance = kvzalloc(struct_size(instance, entry, count), GFP_KERNEL);

Notice that, in this case, variable size is not necessary, hence
it is removed.

This code was detected with the help of Coccinelle.
Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db4863fd
    • Gustavo A. R. Silva's avatar
      cxgb3/l2t: Fix undefined behaviour · 76497732
      Gustavo A. R. Silva authored 
      The use of zero-sized array causes undefined behaviour when it is not
the last member in a structure. As it happens to be in this case.

Also, the current code makes use of a language extension to the C90
standard, but the preferred mechanism to declare variable-length
types such as this one is a flexible array member, 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. Which is beneficial
to cultivate a high-quality code.

Fixes: e48f129c ("[SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference")
Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      76497732
    • Xiaofei Shen's avatar
      net: dsa: read mac address from DT for slave device · a2c7023f
      Xiaofei Shen authored 
      Before creating a slave netdevice, get the mac address from DTS and
apply in case it is valid.
Signed-off-by: default avatarXiaofei Shen <xiaofeis@codeaurora.org>
Signed-off-by: default avatarVinod Koul <vkoul@kernel.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2c7023f
    • Eric Dumazet's avatar
      tcp: fix tcp_inet6_sk() for 32bit kernels · f5d54767
      Eric Dumazet authored 
      It turns out that struct ipv6_pinfo is not located as we think.

inet6_sk_generic() and tcp_inet6_sk() disagree on 32bit kernels by 4-bytes,
because struct tcp_sock has 8-bytes alignment,
but ipv6_pinfo size is not a multiple of 8.

sizeof(struct ipv6_pinfo): 116 (not padded to 8)

I actually first coded tcp_inet6_sk() as this patch does, but thought
that "container_of(tcp_sk(sk), struct tcp6_sock, tcp)" was cleaner.

As Julian told me : Nobody should use tcp6_sock.inet6
directly, it should be accessed via tcp_inet6_sk() or inet6_sk().

This happened when we added the first u64 field in struct tcp_sock.

Fixes: 93a77c11 ("tcp: add tcp_inet6_sk() helper")
Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
Bisected-by: default avatarJulian Anastasov <ja@ssi.bg>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f5d54767
  3. 31 Mar, 2019 6 commits
  5. 29 Mar, 2019 29 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7