Re: [PATCH 08/14] IB/core: Add rdma_max_mad_size helper

["ira.weiny" <ira.weiny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

On Wed, May 20, 2015 at 03:34:04PM -0600, Jason Gunthorpe wrote:
> On Wed, May 20, 2015 at 05:31:28PM -0400, ira.weiny wrote:
> > > I'm not really sure it makes sense to have the drivers set this, since
> > > the value is fixed based on the existing caps. The core could fill it
> > > in, then we don't have to check the driver's work.
> > > 
> > > If the driver fills it then the core should do
> > > 
> > >  BUG_ON(!mad_cap && max_mad_size != 0)
> > 
> > The driver does fill this in, and the core check this as part of this patch.
> > 
> > diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c 
> > index 8055195b5d60..ea25e9467cb5 100644 
> > +++ b/drivers/infiniband/core/mad.c 
> > @@ -2937,6 +2937,10 @@ static int ib_mad_port_open(struct ib_device *device, 
> >         unsigned long flags; 
> >         char name[sizeof "ib_mad123"]; 
> >         int has_smi; 
> > +       size_t max_mad_size = rdma_max_mad_size(device, port_num); 
> > +
> > +       if (WARN_ON(max_mad_size < IB_MGMT_MAD_SIZE))
> > +               return -EFAULT;
> 
> Should be BUG_ON

I think that is a bit strong.  There is nothing in this condition which
warrants a kernel panic.  The WARN_ON allows someone to unload their driver and
fix the problem.

> In the wrong place
> Not the test I asked for.

Right, sorry I missread your comment because I was more concerned about the
case where a driver specifies they want MAD support but then report 0 for the
MAD size.  That is much more dangerous.

I'll add verification to the immutable data with your check.

Ira

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html