lkml.org 
[lkml]   [2007]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    SubjectRe: [git patches 1/2] warnings: attack valid cases spotted by warnings
    From
    Date
     > I don't buy that performance argument, in this case.  You are already
    > dirtying the same cacheline with other variable initializations.
    >
    > Like I noted in the changeset description (hey, this is precisely why
    > I included it, so that we could have this discussion), IMO the flow of
    > control makes it not only impossible for the compiler to understand
    > the full value range of 'f0', but also difficult for humans as well.
    >
    > I could perhaps understand initializing the variable to some poison
    > value rather than zero, but IMO the code is stronger with f0 set to a
    > sane value.

    The more I think about it, the less sense initializing f0 to 0 makes.
    The whole problem with an uninitialized variable is that a random
    value from the stack might be used. So setting a variable to
    something meaningless (guaranteeing that a garbage value is used in
    case of a bug) just to shut up a warning makes no sense -- it's no
    safer than leaving the code as is. uninitialized_var() gets rid of
    the warning, saves a little text and instruction cache, and documents
    things better.

    (BTW, I agree the code is a little confusing as written. I think
    things could be cleaned up and made more efficient by getting rid of
    the initialization of size0 too -- I'll look at doing that)

    Anyway, I queued this up for my next merge with Linus:

    commit 6d7d080e9f7cd535a8821efd3835c5cfa5223ab6
    Author: Roland Dreier <rolandd@cisco.com>
    Date: Tue Jul 17 19:30:51 2007 -0700

    IB/mthca: Use uninitialized_var() for f0

    Commit 9db48926 ("drivers/infiniband/hw/mthca/mthca_qp: kill uninit'd
    var warning") added "= 0" to the declarations of f0 to shut up gcc
    warnings. However, there's no point in making the code bigger by
    initializing f0 to a random value just to get rid of a warning;
    setting f0 to 0 is no safer than just using uninitialized_var(), which
    documents the situation better and gives smaller code too. For example,
    on x86_64:

    add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-16 (-16)
    function old new delta
    mthca_tavor_post_send 1352 1344 -8
    mthca_arbel_post_send 1489 1481 -8

    Signed-off-by: Roland Dreier <rolandd@cisco.com>

    diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c b/drivers/infiniband/hw/mthca/mthca_qp.c
    index 11f1d99..0e9ef24 100644
    --- a/drivers/infiniband/hw/mthca/mthca_qp.c
    +++ b/drivers/infiniband/hw/mthca/mthca_qp.c
    @@ -1591,7 +1591,13 @@ int mthca_tavor_post_send(struct ib_qp *ibqp, struct ib_send_wr *wr,
    int i;
    int size;
    int size0 = 0;
    - u32 f0 = 0;
    + /*
    + * f0 is only used if nreq != 0, and f0 will be initialized
    + * the first time through the main loop, since size0 == 0 the
    + * first time through. So nreq cannot become non-zero without
    + * initializing f0, and f0 is in fact never used uninitialized.
    + */
    + u32 uninitialized_var(f0);
    int ind;
    u8 op0 = 0;

    @@ -1946,7 +1952,13 @@ int mthca_arbel_post_send(struct ib_qp *ibqp, struct ib_send_wr *wr,
    int i;
    int size;
    int size0 = 0;
    - u32 f0 = 0;
    + /*
    + * f0 is only used if nreq != 0, and f0 will be initialized
    + * the first time through the main loop, since size0 == 0 the
    + * first time through. So nreq cannot become non-zero without
    + * initializing f0, and f0 is in fact never used uninitialized.
    + */
    + u32 uninitialized_var(f0);
    int ind;
    u8 op0 = 0;

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/
    \
     
     \ /
      Last update: 2007-07-18 04:43    [W:2.323 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site