[ewg] OFED-1.3.2-20080728-0355.tgz issues (now talking about warnings)

[Betsy Zeller]

In last Monday's OFED meeting, we talked about the importance of
resolving 
the  1800+ warnings currently generated when the nightly build
is installed/built on an RHEL system. SLES seems just as bad.

This many warnings makes it pretty much impossible to note when
a critical one appears - in fact, it's pretty likely that there
are important ones we are already missing. Also, we talked in
Sonoma about all the things we needed to do to truly make
OFED an "Enterprise" release. This is one of them.

Can the owners of the various components take a stab at getting
rid of their warnings, both for SLES and RHEL? It would help us
all to be able to look clearly at what's left when the ones
that are just "noisy" have been cleaned up. The target we
discussed in Monday's meeting was to get these cleaned up
by the OFED 1.4 RC3 release. Let's give it a try.

- Betsy

On Thu, 2008-09-11 at 23:42 +0300, Eli Cohen wrote:
> > 
> > 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].
> _______________________________________________
> ewg mailing list
> ewg at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
-- 
Betsy Zeller
Director of Software Engineering
HSG InfiniBand Engineering
QLogic Corporation
2071 Stierlin Court, Suite 200
Mountain View, CA, 94043
1-650-934-8088