From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CA7CC2D0FA for ; Wed, 13 May 2020 10:45:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6D13C20675 for ; Wed, 13 May 2020 10:45:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HtVeYD1X" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730149AbgEMKpm (ORCPT ); Wed, 13 May 2020 06:45:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726907AbgEMKpl (ORCPT ); Wed, 13 May 2020 06:45:41 -0400 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78592C061A0C for ; Wed, 13 May 2020 03:45:41 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id h17so11379443wrc.8 for ; Wed, 13 May 2020 03:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=h9LKxYkLC3cZPXq+laEeV557r/s5o1tT2d7/UJCfWEw=; b=HtVeYD1X68+YeXK5rktpjuVUrUOubVK/KHKJXYd2QTqVQGMlaUggSW+wZ65oAjafe5 I+SzKhP50Zwfc0xIu9kioGmpw8KQA1j2++hax6G1n6/BEprMRT+Ql/y8QJOlRDc4i2HS MLlDFGe9TDIMju7vPkKd2YkA9sSXlUfxBaYZLOU/GEsgCzT+3tF+jU2JTiboPZQOUTnU 3K033GbPZ0BOb/Dm9oAMXYKKwtw3oqP0ojzBBy4470oSMZ7dZSjVvoc97aZs32tSc61C 9Qv8REGKcB1ooXAvsVnlM055GLAFb58hyEFd7CxupJwG6Mja729G9j55PLBFNRokG/6a r4nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=h9LKxYkLC3cZPXq+laEeV557r/s5o1tT2d7/UJCfWEw=; b=lsIf4KYMSWj5ZDuqvK7DSoZaWRqmHborJYz6+NSSbIbc3TkUcZb/sm2mk23wzU+6J0 Nr6594R5DLnbmXe3zApvMJ2JfvpqhyT2/WK+gJODwsgDr2vJ9gpViM7AWi1JtZHD465C RWQsm6zaT7/b1RndqweGQVnLxNL0Bnu541WlhL+yI1XK0/Fx2uLMXLDpmEAPOvWVGURU lKW4Bo2pG+EYEomgRmAyqVeDgAFrBwrwkaY9DOOqePRQptdKG8hpZVS0gobT6kqZuRNU ySKmAM452fnpa8z/t5DlnLOW5DWsI5AX91Hij/xnG/u16Ehr1LVhYHWvYhSoAb5i1ROO p0OQ== X-Gm-Message-State: AGi0PuYH6/CBExQuzcE1t9EW0Yvh18STrnI9gZ9iRe3ZCl+w93xG7kXt 4RrRzsv1DssdbKQxC2h7qfg= X-Google-Smtp-Source: APiQypKYH9pj4xTY8VL32XR56a9gNwm5DGloQIKslqJh9saYsy2TmZ/+3BcsF2iyqyzCopro+WzJ+A== X-Received: by 2002:adf:aacb:: with SMTP id i11mr30518556wrc.6.1589366740181; Wed, 13 May 2020 03:45:40 -0700 (PDT) Received: from kheib-workstation ([37.142.4.4]) by smtp.gmail.com with ESMTPSA id v11sm27281657wrv.53.2020.05.13.03.45.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2020 03:45:39 -0700 (PDT) Date: Wed, 13 May 2020 13:45:36 +0300 From: Kamal Heib To: Leon Romanovsky Cc: linux-rdma@vger.kernel.org, Doug Ledford , Jason Gunthorpe , Bart Van Assche Subject: Re: [PATCH for-rc] RDMA/srpt: Fix disabling device management Message-ID: <20200513104536.GA120318@kheib-workstation> References: <20200511222918.62576-1-kamalheib1@gmail.com> <20200513072203.GR4814@unreal> <20200513100204.GA92901@kheib-workstation> <20200513102132.GW4814@unreal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200513102132.GW4814@unreal> Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Wed, May 13, 2020 at 01:21:32PM +0300, Leon Romanovsky wrote: > On Wed, May 13, 2020 at 01:02:04PM +0300, Kamal Heib wrote: > > On Wed, May 13, 2020 at 10:22:03AM +0300, Leon Romanovsky wrote: > > > On Tue, May 12, 2020 at 01:29:18AM +0300, Kamal Heib wrote: > > > > Avoid disabling device management for devices that don't support > > > > Management datagrams (MADs) by checking if the "mad_agent" pointer is > > > > initialized before calling ib_modify_port, also change the error message > > > > to a warning and make it more informative. > > > > > > > > Fixes: 09f8a1486dca ("RDMA/srpt: Fix handling of SR-IOV and iWARP ports") > > > > Signed-off-by: Kamal Heib > > > > --- > > > > drivers/infiniband/ulp/srpt/ib_srpt.c | 8 ++++++-- > > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c > > > > index 7ed38d1cb997..7b21792ab6f7 100644 > > > > --- a/drivers/infiniband/ulp/srpt/ib_srpt.c > > > > +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c > > > > @@ -625,14 +625,18 @@ static void srpt_unregister_mad_agent(struct srpt_device *sdev) > > > > .clr_port_cap_mask = IB_PORT_DEVICE_MGMT_SUP, > > > > }; > > > > struct srpt_port *sport; > > > > + int ret; > > > > int i; > > > > > > > > for (i = 1; i <= sdev->device->phys_port_cnt; i++) { > > > > sport = &sdev->port[i - 1]; > > > > WARN_ON(sport->port != i); > > > > - if (ib_modify_port(sdev->device, i, 0, &port_modify) < 0) > > > > - pr_err("disabling MAD processing failed.\n"); > > > > if (sport->mad_agent) { > > > > + ret = ib_modify_port(sdev->device, i, 0, &port_modify); > > > > + if (ret < 0) > > > > + pr_warn("%s-%d: disabling device management failed (%d). Note: this is expected if SR-IOV is enabled.\n", > > > > + dev_name(&sport->sdev->device->dev), > > > > > > The ib_modify_port() shouldn't be called if it expected to fail. > > > > > > Thanks > > > > OK, Do you know if there is a way to check if the created ib device is > > for VF to avoid calling ib_modify_port()? > > The "is_virtfn" field inside pci_dev will give this information, > but I don't know why it is expected to fail here. > > Thanks > Looks like there a more trivial way, I mean checking if IB_DEVICE_VIRTUAL_FUNCTION cap is set, probably there is a need to make to sure that this cap is set for all providers when the IB device is created for a VF. With regards to why it is expected to fail, as stated in the commit message and the in "Fixes" commit message there is some devices (VF) that don't support MADs. Thanks, Kamal > > > > Thanks, > > Kamal > > > > > > > > > + sport->port, ret); > > > > ib_unregister_mad_agent(sport->mad_agent); > > > > sport->mad_agent = NULL; > > > > } > > > > -- > > > > 2.25.4 > > > >