Messages in this thread Patch in this message | | | Subject | Re: [git patches 1/2] warnings: attack valid cases spotted by warnings | From | Roland Dreier <> | Date | Tue, 17 Jul 2007 19:35:05 -0700 |
| |
> 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/
| |