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

Commit Message

Ira Weiny May 20, 2015, 9:31 p.m. UTC

On Wed, May 20, 2015 at 01:43:14PM -0600, Jason Gunthorpe wrote:
> On Wed, May 20, 2015 at 03:03:52PM -0400, ira.weiny wrote:
> > On Wed, May 20, 2015 at 12:19:28PM -0600, Jason Gunthorpe wrote:
> > > On Wed, May 20, 2015 at 02:02:27PM -0400, ira.weiny wrote:
> > > > On Wed, May 20, 2015 at 11:37:47AM -0600, Hefty, Sean wrote:
> > > > > > +/**
> > > > > > + * rdma_max_mad_size - Return the max MAD size required by this RDMA
> > > > > > Port.
> > > > > > + *
> > > > > > + * @device: Device
> > > > > > + * @port_num: Port number
> > > > > > + *
> > > > > > + * Return the max MAD size required by the Port.  Should return 0 if the
> > > > > > port
> > > > > > + * does not support MADs
> > > > > > + */
> > > > > > +static inline size_t rdma_max_mad_size(struct ib_device *device, u8
> > > > > > port_num)
> > > > > > +{
> > > > > > +	return device->port_immutable[port_num].max_mad_size;
> > > > > > +}
> > > > > 
> > > > > Should this function check the mad_cap bit and return 0 if not set?  If not,
> > > > > I would remove the 'should return 0...' statement from the comment above and
> > > > > state that the caller should check the mad_cap bit first.
> > > > 
> > > > I'll change the comment.
> > > 
> > > If there is no mad support the port_immutable.max_mad_size should be
> > > 0, force it during registration, then the comment is right.
> > > 
> > > Force to 0 is better than 'some random value'
> > 
> > When you say "force" do you mean have the drivers which don't support MAD
> > explicitly set it to 0?
> 
> 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.



> 
> After calling the driver to fill the values.
> 
> The comment seems OK (change Should => Will), it is describing the
> function, and the function should be the only accessor for this value,
> so it also describes the value. Maybe clarify what mad size is .. Is
> it just the payload?

I'll add this to the comment,
Ira

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Jason Gunthorpe May 20, 2015, 9:34 p.m. UTC | #1

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
In the wrong place
Not the test I asked for.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ira Weiny May 21, 2015, 12:12 a.m. UTC | #2

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 [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c 
index 8055195b5d60..ea25e9467cb5 100644 
--- a/drivers/infiniband/core/mad.c 
+++ 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;

        /* Create new device info */
        port_priv = kzalloc(sizeof *port_priv, GFP_KERNEL);