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: Tue, 12 May 2015 09:07:51 +0300	[thread overview]
Message-ID: <555198B7.40302@mellanox.com> (raw)
In-Reply-To: <20150511181824.GA25405@obsidianresearch.com>

On 11/05/2015 21:18, Jason Gunthorpe wrote:
> 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.

Right. Sorry I missed that. Our first draft just kept the addition and
removal of elements to the device or client list under the mutex,
thinking that only the new code in this patchset that does traversal of
the lists would use the SRCU read lock. We then changed it thinking that
it would be better to make some use of this SRCU in this patch as well.

> 
> 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..]

So, I'm not very familiar with that code, but it seems that the main
difference is that in the core a single driver can be attached to a
device. The device_add function calls bus_add_device to add it to the
bus's list, and and later calls bus_probe_device to find a driver,
without any lock between these calls. And bus_add_driver adds a new
driver to the bus's driver list and then calls driver_attach without any
lock between them. The only thing I see that makes sure a driver won't
be attached twice to a device is the dev->driver field which is updated
under the device lock during the probing process.

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?

Haggai

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: Tue, 12 May 2015 09:07:51 +0300	[thread overview]
Message-ID: <555198B7.40302@mellanox.com> (raw)
In-Reply-To: <20150511181824.GA25405@obsidianresearch.com>

On 11/05/2015 21:18, Jason Gunthorpe wrote:
> 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.

Right. Sorry I missed that. Our first draft just kept the addition and
removal of elements to the device or client list under the mutex,
thinking that only the new code in this patchset that does traversal of
the lists would use the SRCU read lock. We then changed it thinking that
it would be better to make some use of this SRCU in this patch as well.

> 
> 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..]

So, I'm not very familiar with that code, but it seems that the main
difference is that in the core a single driver can be attached to a
device. The device_add function calls bus_add_device to add it to the
bus's list, and and later calls bus_probe_device to find a driver,
without any lock between these calls. And bus_add_driver adds a new
driver to the bus's driver list and then calls driver_attach without any
lock between them. The only thing I see that makes sure a driver won't
be attached twice to a device is the dev->driver field which is updated
under the device lock during the probing process.

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?

Haggai

  reply	other threads:[~2015-05-12  6:07 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 [this message]
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
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
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
     [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 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=555198B7.40302@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.