All of lore.kernel.org
 help / color / mirror / Atom feed
From: Haggai Eran <haggaie@mellanox.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.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: Thu, 14 May 2015 13:35:36 +0300	[thread overview]
Message-ID: <55547A78.5080404@mellanox.com> (raw)
In-Reply-To: <20150513155737.GA16941@obsidianresearch.com>

On 13/05/2015 18:57, Jason Gunthorpe wrote:
> On Wed, May 13, 2015 at 11:10:15AM +0300, Haggai Eran wrote:
> 
>>>> I guess a similar thing we can do is to rely on the context we associate
>>>> with a pair of a client and a device. If such a context exist, we don't
>>>> need to call client->add again. What do you think?
>>>
>>> I didn't look closely, isn't this enough?
>>>
>>> device_register:
>>>  mutex_lock(client_mutex);
>>>  down_write(devices_rwsem);
>>>  list_add(device_list,dev,..);
>>>  up_write(devices_rwsem);
>>>
>>>  /* Caller must prevent device_register/unregister concurrancy on the
>>>     same dev */
>>>
>>>  foreach(client_list)
>>>    .. client->add(dev,...) .. 
>>>
>>>  mutex_unlock(client_mutex)
>>>
>>> client_register:
>>>  mutex_lock(client_mutex)
>>>  list_add(client_list,new_client..)
>>>  down_read(devices_rwsem);
>>>  foreach(device_list)
>>>    .. client->add(dev,new_client,..) ..
>>>  up_read(devices_rwsem);
>>>  mutex_unlock(client_mutex)
>>>
>>> [Note, I didn't check this carefully, just intuitively seems like a
>>>  sane starting point]
>>
>> That could perhaps work for the RoCEv2 patch-set, as their deadlock
>> relates to iterating the device list. This patch set however does an
>> iteration on the client list (patch 3). Because a client remove could
>> block on this iteration, you can still get a deadlock.
> 
> Really? Gross.
> 
> Still, I think you got it right in your analysis, but we don't need RCU:
> 
> device_register:
>  mutex_lock(modify_mutex);
>  down_write(lists_rwsem);
>  list_add(device_list,dev,..);
>  up_write(lists_rwsem);
> 
>  // implied by modify_mutex: down_read(lists_rwsem)
>  foreach(client_list)
>     .. client->add(dev,...) ..
>  mutex_unlock(modify_mutex)
> 
> client_register:
>  mutex_lock(modify_mutex);
>  // implied by modify_mutex: down_read(lists_rwsem)
>  foreach(device_list)
>     .. client->add(dev,new_client...) ..
> 
>  down_write(lists_rwsem);
>  list_add(client_list,new_client..);
>  up_write(lists_rwsem);
> 
>  mutex_unlock(modify_mutex)
> 
> client_unregister:
>  mutex_lock(modify_mutex);
>  down_write(lists_rwsem);
>  list_cut(client_list,..rm_client..);
>  up_write(lists_rwsem);
> 
>  // implied by modify_mutex: down_read(lists_rwsem)
>  foreach(device_list)
>     .. client->remove(dev,rm_client...) ..
> 
>  mutex_unlock(modify_mutex)
> 
> etc. Notice the ordering.
> 

Looks good. I'll use it in the next version of the patch.

WARNING: multiple messages have this Message-ID (diff)
From: Haggai Eran <haggaie@mellanox.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.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: Thu, 14 May 2015 13:35:36 +0300	[thread overview]
Message-ID: <55547A78.5080404@mellanox.com> (raw)
In-Reply-To: <20150513155737.GA16941@obsidianresearch.com>

On 13/05/2015 18:57, Jason Gunthorpe wrote:
> On Wed, May 13, 2015 at 11:10:15AM +0300, Haggai Eran wrote:
> 
>>>> I guess a similar thing we can do is to rely on the context we associate
>>>> with a pair of a client and a device. If such a context exist, we don't
>>>> need to call client->add again. What do you think?
>>>
>>> I didn't look closely, isn't this enough?
>>>
>>> device_register:
>>>  mutex_lock(client_mutex);
>>>  down_write(devices_rwsem);
>>>  list_add(device_list,dev,..);
>>>  up_write(devices_rwsem);
>>>
>>>  /* Caller must prevent device_register/unregister concurrancy on the
>>>     same dev */
>>>
>>>  foreach(client_list)
>>>    .. client->add(dev,...) .. 
>>>
>>>  mutex_unlock(client_mutex)
>>>
>>> client_register:
>>>  mutex_lock(client_mutex)
>>>  list_add(client_list,new_client..)
>>>  down_read(devices_rwsem);
>>>  foreach(device_list)
>>>    .. client->add(dev,new_client,..) ..
>>>  up_read(devices_rwsem);
>>>  mutex_unlock(client_mutex)
>>>
>>> [Note, I didn't check this carefully, just intuitively seems like a
>>>  sane starting point]
>>
>> That could perhaps work for the RoCEv2 patch-set, as their deadlock
>> relates to iterating the device list. This patch set however does an
>> iteration on the client list (patch 3). Because a client remove could
>> block on this iteration, you can still get a deadlock.
> 
> Really? Gross.
> 
> Still, I think you got it right in your analysis, but we don't need RCU:
> 
> device_register:
>  mutex_lock(modify_mutex);
>  down_write(lists_rwsem);
>  list_add(device_list,dev,..);
>  up_write(lists_rwsem);
> 
>  // implied by modify_mutex: down_read(lists_rwsem)
>  foreach(client_list)
>     .. client->add(dev,...) ..
>  mutex_unlock(modify_mutex)
> 
> client_register:
>  mutex_lock(modify_mutex);
>  // implied by modify_mutex: down_read(lists_rwsem)
>  foreach(device_list)
>     .. client->add(dev,new_client...) ..
> 
>  down_write(lists_rwsem);
>  list_add(client_list,new_client..);
>  up_write(lists_rwsem);
> 
>  mutex_unlock(modify_mutex)
> 
> client_unregister:
>  mutex_lock(modify_mutex);
>  down_write(lists_rwsem);
>  list_cut(client_list,..rm_client..);
>  up_write(lists_rwsem);
> 
>  // implied by modify_mutex: down_read(lists_rwsem)
>  foreach(device_list)
>     .. client->remove(dev,rm_client...) ..
> 
>  mutex_unlock(modify_mutex)
> 
> etc. Notice the ordering.
> 

Looks good. I'll use it in the next version of the patch.

  reply	other threads:[~2015-05-14 10:35 UTC|newest]

Thread overview: 46+ 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
2015-05-12  6:07     ` Haggai Eran
2015-05-12  6:07       ` Haggai Eran
2015-05-12 18:23       ` Jason Gunthorpe
2015-05-13  8:10         ` Haggai Eran
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 [this message]
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
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 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-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=55547A78.5080404@mellanox.com \
    --to=haggaie@mellanox.com \
    --cc=dledford@redhat.com \
    --cc=guysh@mellanox.com \
    --cc=jgunthorpe@obsidianresearch.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.