[ewg] OFED-1.3.2-20080728-0355.tgz issues

[Eli Cohen]

> 
> Whether it showed up as a problem or not, the compiler warning was an
> array out of bounds warning.  That's not the type of compiler warning
> that should be ignored as it almost always points to a bug.  I guess I
> was a little surprised that even though the compile tests on the kernel
> pass, that you guys allow that type of warning to go unchecked.  I make
> a habit out of reviewing kernel compile warnings on the code I maintain
> and, when possible, I fix all the warnings just so things like this get
> caught.
> 
I totally agree with you; this warning must have lost in the multitude
of compiler messages.

> >  Anyway, I think I
> > prefer this fix to the same problem:
> > 
> > Index: ofed_kernel-fixes/drivers/infiniband/ulp/ipoib/ipoib_verbs.c
> > ===================================================================
> > --- ofed_kernel-fixes.orig/drivers/infiniband/ulp/ipoib/ipoib_verbs.c	2008-09-08 13:07:02.000000000 +0300
> > +++ ofed_kernel-fixes/drivers/infiniband/ulp/ipoib/ipoib_verbs.c	2008-09-08 13:08:41.000000000 +0300
> > @@ -234,7 +234,7 @@ int ipoib_transport_dev_init(struct net_
> >  		if (i < UD_POST_RCV_COUNT - 1)
> >  			priv->rx_wr_draft[i].next = &priv->rx_wr_draft[i + 1];
> >  	}
> > -	priv->rx_wr_draft[i].next = NULL;
> > +	priv->rx_wr_draft[UD_POST_RCV_COUNT - 1].next = NULL;
> >  
> >  	if (ipoib_ud_need_sg(priv->max_ib_mtu)) {
> >  		for (i = 0; i < UD_POST_RCV_COUNT; ++i) {
> > 
> > What do you think?
> 
> If you're going to keep the setting of the last item to NULL outside the
> loop, then you can also remove the if inside the loop as you'll just
> overwrite the last entry when you exit the loop.
> 
Well, yes, but then I am going to reference an entry outside the
bounds of the array, which we want to prevent in the first place.

        priv->rx_wr_draft[i].next = &priv->rx_wr_draft[i + 1];

without the "if", priv->rx_wr_draft[i + 1] refrence
priv->rx_wr_draft[UD_POST_RCV_COUNT].