From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Haggai Eran <haggaie@mellanox.com>
Cc: Doug Ledford <dledford@redhat.com>,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
Liran Liss <liranl@mellanox.com>,
Guy Shapiro <guysh@mellanox.com>,
Shachar Raindel <raindel@mellanox.com>,
Yotam Kenneth <yotamke@mellanox.com>,
Matan Barak <matanb@mellanox.com>
Subject: Re: [PATCH v3 for-next 01/13] IB/core: Use SRCU when reading client_list or device_list
Date: Mon, 11 May 2015 12:18:24 -0600 [thread overview]
Message-ID: <20150511181824.GA25405@obsidianresearch.com> (raw)
In-Reply-To: <1431253604-9214-2-git-send-email-haggaie@mellanox.com>
On Sun, May 10, 2015 at 01:26:32PM +0300, Haggai Eran wrote:
> Currently the RDMA subsystem's device list and client list are protected by
> a single mutex. This prevents adding user-facing APIs that iterate these
> lists, since using them may cause a deadlock. The patch attempts to solve
> this problem by adding an SRCU to protect the lists. Readers now don't need
> the mutex, and are safe just by using srcu_read_lock/unlock.
>
> The ib_register_device, ib_register_client, and ib_unregister_client
> functions are modified to only lock the device_mutex during their
> respective list modification, and use the SRCU for iteration on the other
> list. In ib_unregister_device, the client list iteration remains in the
> mutex critical section as it is done in reverse order.
>
> This patch attempts to solve a similar need [1] that was seen in the RoCE
> v2 patch series.
>
> [1] http://www.spinics.net/lists/linux-rdma/msg24733.html
So at first blush this looked reasonable, but, no it is racy:
ib_register_client:
mutex_lock(&device_mutex);
list_add_tail_rcu(&client->list, &client_list);
mutex_unlock(&device_mutex);
id = srcu_read_lock(&device_srcu);
list_for_each_entry_rcu(device, &device_list, core_list)
client->add(device);
ib_register_device:
mutex_lock(&device_mutex);
list_add_tail(&device->core_list, &device_list);
mutex_unlock(&device_mutex);
id = srcu_read_lock(&device_srcu);
list_for_each_entry_rcu(client, &client_list, list)
client->add(device);
So, if two threads call the two registers then the new client will
have it's add called twice on the same device.
There are similar problems with removal.
I'm not sure RCU is the right way to approach this. The driver core
has the same basic task to perform, maybe review it's locking
arrangment between the device list and driver list.
[Actually we probably should be using the driver core here, with IB
clients as device drivers, but that is way beyond scope of this..]
I had a bunch of other comments, but they are not relevant,
considering the above.
Jason
next prev parent reply other threads:[~2015-05-11 18:18 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-10 10:26 [PATCH v3 for-next 00/13] Add network namespace support in the RDMA-CM Haggai Eran
2015-05-10 10:26 ` [PATCH v3 for-next 01/13] IB/core: Use SRCU when reading client_list or device_list Haggai Eran
2015-05-11 18:18 ` Jason Gunthorpe [this message]
2015-05-12 6:07 ` Haggai Eran
2015-05-12 18:23 ` Jason Gunthorpe
2015-05-13 8:10 ` Haggai Eran
[not found] ` <555306E7.9020000-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2015-05-13 15:57 ` Jason Gunthorpe
2015-05-14 10:35 ` Haggai Eran
2015-05-10 10:26 ` [PATCH v3 for-next 02/13] IB/addr: Pass network namespace as a parameter Haggai Eran
[not found] ` <1431253604-9214-1-git-send-email-haggaie-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2015-05-10 10:26 ` [PATCH v3 for-next 03/13] IB/core: Find the network namespace matching connection parameters Haggai Eran
2015-05-10 10:26 ` [PATCH v3 for-next 04/13] IB/ipoib: Return IPoIB devices " Haggai Eran
2015-05-10 10:26 ` [PATCH v3 for-next 06/13] IB/cm: API to retrieve existing listening CM IDs Haggai Eran
2015-05-10 10:26 ` [PATCH v3 for-next 07/13] IB/cm: Expose service ID in request events Haggai Eran
2015-05-10 10:26 ` [PATCH v3 for-next 05/13] IB/cm: Reference count ib_cm_ids Haggai Eran
[not found] ` <1431253604-9214-6-git-send-email-haggaie-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2015-05-11 18:34 ` Jason Gunthorpe
2015-05-12 6:50 ` Haggai Eran
[not found] ` <5551A2CB.1010407-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2015-05-12 18:54 ` Jason Gunthorpe
[not found] ` <20150512185447.GA3503-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-05-13 10:20 ` Haggai Eran
2015-05-13 16:58 ` Jason Gunthorpe
[not found] ` <20150513165823.GA20343-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-05-14 6:48 ` Haggai Eran
2015-05-15 19:11 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373A8FDC0C3-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-05-17 6:27 ` Haggai Eran
2015-05-19 19:23 ` Jason Gunthorpe
[not found] ` <20150519192353.GA23612-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-05-19 22:52 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373A8FDD412-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-05-19 23:46 ` Jason Gunthorpe
[not found] ` <20150519234654.GA26634-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-05-20 0:49 ` Hefty, Sean
2015-05-21 6:51 ` Haggai Eran
[not found] ` <555D806B.1090002-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2015-05-21 12:56 ` Hefty, Sean
2015-05-10 10:26 ` [PATCH v3 for-next 08/13] IB/cma: Refactor RDMA IP CM private-data parsing code Haggai Eran
2015-05-10 10:26 ` [PATCH v3 for-next 09/13] IB/cma: Add compare_data checks to the RDMA CM module Haggai Eran
2015-05-10 10:26 ` [PATCH v3 for-next 10/13] IB/cma: Separate port allocation to network namespaces Haggai Eran
2015-05-10 10:26 ` [PATCH v3 for-next 11/13] IB/cma: Share CM IDs between namespaces Haggai Eran
2015-05-10 10:26 ` [PATCH v3 for-next 12/13] IB/cma: Add support for network namespaces Haggai Eran
2015-05-10 10:26 ` [PATCH v3 for-next 13/13] IB/ucma: Take the network namespace from the process Haggai Eran
2015-05-12 17:52 ` [PATCH v3 for-next 00/13] Add network namespace support in the RDMA-CM Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373A8FD7B85-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-05-13 8:50 ` Haggai Eran
[not found] ` <55531073.1000305-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2015-05-13 16:45 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373A8FDA13B-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-05-13 17:18 ` Jason Gunthorpe
[not found] ` <20150513171823.GB20343-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2015-05-13 17:30 ` Hefty, Sean
[not found] ` <1828884A29C6694DAF28B7E6B8A82373A8FDA1AB-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2015-05-14 5:35 ` Haggai Eran
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=20150511181824.GA25405@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=dledford@redhat.com \
--cc=guysh@mellanox.com \
--cc=haggaie@mellanox.com \
--cc=linux-rdma@vger.kernel.org \
--cc=liranl@mellanox.com \
--cc=matanb@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=raindel@mellanox.com \
--cc=yotamke@mellanox.com \
/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).