From: Long Li <longli@microsoft.com>
To: Yunsheng Lin <linyunsheng@huawei.com>,
KY Srinivasan <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
"edumazet@google.com" <edumazet@google.com>,
"shiraz.saleem@intel.com" <shiraz.saleem@intel.com>,
Ajay Sharma <sharmaajay@microsoft.com>
Cc: "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: RE: [Patch v9 03/12] net: mana: Handle vport sharing between devices
Date: Tue, 25 Oct 2022 01:43:16 +0000 [thread overview]
Message-ID: <PH7PR21MB3263EBADFD177761BB978D6ACE319@PH7PR21MB3263.namprd21.prod.outlook.com> (raw)
In-Reply-To: <38cedbd0-b719-eab5-71bd-2677462096c5@huawei.com>
> >>> @@ -679,9 +714,16 @@ static int mana_cfg_vport(struct
> >>> mana_port_context *apc, u32 protection_dom_id,
> >>>
> >>> apc->tx_shortform_allowed = resp.short_form_allowed;
> >>> apc->tx_vp_offset = resp.tx_vport_offset;
> >>> +
> >>> + netdev_info(apc->ndev, "Configured vPort %llu PD %u DB %u\n",
> >>> + apc->port_handle, protection_dom_id, doorbell_pg_id);
> >>> out:
> >>> + if (err)
> >>> + mana_uncfg_vport(apc);
> >>
> >> There seems to be a similar race between error handling here and the
> >> "apc-
> >>> vport_use_count > 0" checking above as pointed out in v7.
> >
> > Thanks for looking into this.
> >
> > This is different to the locking bug in mana_ib_cfg_vport(). The vport
> > sharing between Ethernet and RDMA is exclusive, not shared. If another
> > driver tries to take the vport while it is being configured, it will
> > fail immediately. It is by
>
> Suppose the following steps:
> 1. Ethernet driver take the lock first and do a "apc->vport_use_count++",
> and
> release the lock;
> 2. RDMA driver take the lock, do "apc->vport_use_count > 0" checking and
> return
> -EBUSY;
> 3. mana_send_request() or mana_verify_resp_hdr() return error to
> Ethernet driver.
>
> It seems that vport is left unused when above happens, if that is what you
> wanted?
Yes, in this case the vport is left unused. There is no resource leak.
This is expected.
>
>
> > design to prevent possible deadlock.
>
> I am not sure I understand the deadlock here.
Because we are dealing with two drivers. I don't want to block as
mana_send_request() is a blocking call.
next prev parent reply other threads:[~2022-10-25 1:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-22 0:01 [Patch v9 00/12] Introduce Microsoft Azure Network Adapter (MANA) RDMA driver longli
2022-10-22 0:01 ` [Patch v9 01/12] net: mana: Add support for auxiliary device longli
2022-10-22 0:01 ` [Patch v9 02/12] net: mana: Record the physical address for doorbell page region longli
2022-10-22 0:01 ` [Patch v9 03/12] net: mana: Handle vport sharing between devices longli
2022-10-24 1:20 ` Yunsheng Lin
2022-10-24 18:45 ` Long Li
2022-10-25 1:08 ` Yunsheng Lin
2022-10-25 1:43 ` Long Li [this message]
2022-10-22 0:01 ` [Patch v9 04/12] net: mana: Set the DMA device max segment size longli
2022-10-22 0:01 ` [Patch v9 05/12] net: mana: Export Work Queue functions for use by RDMA driver longli
2022-10-22 0:01 ` [Patch v9 06/12] net: mana: Record port number in netdev longli
2022-10-22 0:01 ` [Patch v9 07/12] net: mana: Move header files to a common location longli
2022-10-22 0:01 ` [Patch v9 08/12] net: mana: Define max values for SGL entries longli
2022-10-22 0:01 ` [Patch v9 09/12] net: mana: Define and process GDMA response code GDMA_STATUS_MORE_ENTRIES longli
2022-10-22 0:01 ` [Patch v9 10/12] net: mana: Define data structures for allocating doorbell page from GDMA longli
2022-10-22 0:01 ` [Patch v9 11/12] net: mana: Define data structures for protection domain and memory registration longli
2022-10-22 0:01 ` [Patch v9 12/12] RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter longli
2022-10-28 17:18 ` Jason Gunthorpe
2022-10-31 19:32 ` Long Li
2022-11-01 17:27 ` Jason Gunthorpe
2022-11-01 18:31 ` Long Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=PH7PR21MB3263EBADFD177761BB978D6ACE319@PH7PR21MB3263.namprd21.prod.outlook.com \
--to=longli@microsoft.com \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=edumazet@google.com \
--cc=haiyangz@microsoft.com \
--cc=jgg@ziepe.ca \
--cc=kuba@kernel.org \
--cc=kys@microsoft.com \
--cc=leon@kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sharmaajay@microsoft.com \
--cc=shiraz.saleem@intel.com \
--cc=sthemmin@microsoft.com \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).