• Arnd Bergmann's avatar
    IB/mlx5: revisit -Wmaybe-uninitialized warning · 1b19b951
    Arnd Bergmann authored
    A warning that I thought I had fixed before occasionally comes
    back in rare randconfig builds (I found 7 instances in the last
    100000 builds, originally it was much more frequent):
    
    drivers/infiniband/hw/mlx5/mr.c: In function 'mlx5_ib_reg_user_mr':
    drivers/infiniband/hw/mlx5/mr.c:1229:5: error: 'order' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      if (order <= mr_cache_max_order(dev)) {
         ^
    drivers/infiniband/hw/mlx5/mr.c:1247:8: error: 'ncont' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    drivers/infiniband/hw/mlx5/mr.c:1247:8: error: 'page_shift' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    drivers/infiniband/hw/mlx5/mr.c:1260:2: error: 'npages' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    
    I've looked at all those findings again and noticed that they are all
    with CONFIG_INFINIBAND_USER_MEM=n, which means ib_umem_get() returns
    an error unconditionally and we never initialize or use those variables.
    This triggers a condition in gcc iff mr_umem_get() is partially but not
    entirely inlined, which in turn depends on the exact combination of
    optimization settings. This is a known problem with gcc, with no
    easy solution in the compiler, so this adds another workaround that
    should be more reliable than my previous attempt.
    
    Returning an error from mlx5_ib_reg_user_mr() earlier means that we
    can completely bypass the logic that caused the warning, the compiler
    can now see that the variable is never accessed.
    
    Fixes: 14ab8896 ("IB/mlx5: avoid bogus -Wmaybe-uninitialized warning")
    Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
    Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
    1b19b951
mr.c 45.3 KB