From patchwork Wed May 20 21:31:28 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ira Weiny X-Patchwork-Id: 6450231 Return-Path: X-Original-To: patchwork-linux-rdma@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 3BB599F318 for ; Wed, 20 May 2015 21:31:36 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5A56020426 for ; Wed, 20 May 2015 21:31:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4DC2F20122 for ; Wed, 20 May 2015 21:31:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753554AbbETVbd (ORCPT ); Wed, 20 May 2015 17:31:33 -0400 Received: from mga09.intel.com ([134.134.136.24]:22625 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753212AbbETVbc (ORCPT ); Wed, 20 May 2015 17:31:32 -0400 Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP; 20 May 2015 14:31:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,466,1427785200"; d="scan'208";a="496260294" Received: from phlsvsds.ph.intel.com ([10.228.195.38]) by FMSMGA003.fm.intel.com with ESMTP; 20 May 2015 14:31:30 -0700 Received: from phlsvsds.ph.intel.com (localhost.localdomain [127.0.0.1]) by phlsvsds.ph.intel.com (8.13.8/8.13.8) with ESMTP id t4KLVTvo011053; Wed, 20 May 2015 17:31:29 -0400 Received: (from iweiny@localhost) by phlsvsds.ph.intel.com (8.13.8/8.13.8/Submit) id t4KLVSFo011050; Wed, 20 May 2015 17:31:28 -0400 X-Authentication-Warning: phlsvsds.ph.intel.com: iweiny set sender to ira.weiny@intel.com using -f Date: Wed, 20 May 2015 17:31:28 -0400 From: "ira.weiny" To: Jason Gunthorpe Cc: "Hefty, Sean" , "dledford@redhat.com" , "linux-rdma@vger.kernel.org" , "hal@dev.mellanox.co.il" Subject: Re: [PATCH 08/14] IB/core: Add rdma_max_mad_size helper Message-ID: <20150520213128.GD22981@phlsvsds.ph.intel.com> References: <1432109615-19564-1-git-send-email-ira.weiny@intel.com> <1432109615-19564-9-git-send-email-ira.weiny@intel.com> <1828884A29C6694DAF28B7E6B8A82373A8FDDACE@ORSMSX109.amr.corp.intel.com> <20150520180226.GC14309@phlsvsds.ph.intel.com> <20150520181928.GE28496@obsidianresearch.com> <20150520190352.GA22981@phlsvsds.ph.intel.com> <20150520194314.GA3344@obsidianresearch.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20150520194314.GA3344@obsidianresearch.com> User-Agent: Mutt/1.4.2.2i Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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);