All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <jglisse@redhat.com>
To: Jason Gunthorpe <jgg@mellanox.com>
Cc: Ralph Campbell <rcampbell@nvidia.com>,
	John Hubbard <jhubbard@nvidia.com>,
	"Felix.Kuehling@amd.com" <Felix.Kuehling@amd.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
	Ben Skeggs <bskeggs@redhat.com>, Michal Hocko <mhocko@kernel.org>
Subject: Re: [PATCH hmm 02/15] mm/mmu_notifier: add an interval tree notifier
Date: Mon, 21 Oct 2019 15:47:48 -0400	[thread overview]
Message-ID: <20191021194748.GA5644@redhat.com> (raw)
In-Reply-To: <20191021192448.GK6285@mellanox.com>

On Mon, Oct 21, 2019 at 07:24:53PM +0000, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 03:11:57PM -0400, Jerome Glisse wrote:
> > > Since that reader is not locked we need release semantics here to
> > > ensure the unlocked reader sees a fully initinalized mmu_notifier_mm
> > > structure when it observes the pointer.
> > 
> > I thought the mm_take_all_locks() would have had a barrier and thus
> > that you could not see mmu_notifier struct partialy initialized. 
> 
> Not sure, usually a lock acquire doesn't have a store barrier?

Yeah likely.

> 
> Even if it did, we would still need some pairing read barrier..
> 
> > having the acquire/release as safety net does not hurt. Maybe add a
> > comment about the struct initialization needing to be visible before
> > pointer is set.
> 
> Is this clear?
> 
>          * release semantics on the initialization of the
>          * mmu_notifier_mm's contents are provided for unlocked readers.
> 	 * acquire can only be used while holding the
>          * mmgrab or mmget, and is safe because once created the
>          * mmu_notififer_mm is not freed until the mm is destroyed.
>          * Users holding the mmap_sem or one of the
> 	 * mm_take_all_locks() do not need to use acquire semantics.
> 
> It also helps explain why there is no locking around the other
> readers, which has puzzled me in the past at least.

Perfect.

Jérôme


WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Jason Gunthorpe <jgg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
Cc: Andrea Arcangeli
	<aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Ralph Campbell
	<rcampbell-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	John Hubbard <jhubbard-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"Felix.Kuehling-5C7GfCeVMHo@public.gmane.org"
	<Felix.Kuehling-5C7GfCeVMHo@public.gmane.org>,
	"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org"
	<linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH hmm 02/15] mm/mmu_notifier: add an interval tree notifier
Date: Mon, 21 Oct 2019 15:47:48 -0400	[thread overview]
Message-ID: <20191021194748.GA5644@redhat.com> (raw)
In-Reply-To: <20191021192448.GK6285-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>

On Mon, Oct 21, 2019 at 07:24:53PM +0000, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 03:11:57PM -0400, Jerome Glisse wrote:
> > > Since that reader is not locked we need release semantics here to
> > > ensure the unlocked reader sees a fully initinalized mmu_notifier_mm
> > > structure when it observes the pointer.
> > 
> > I thought the mm_take_all_locks() would have had a barrier and thus
> > that you could not see mmu_notifier struct partialy initialized. 
> 
> Not sure, usually a lock acquire doesn't have a store barrier?

Yeah likely.

> 
> Even if it did, we would still need some pairing read barrier..
> 
> > having the acquire/release as safety net does not hurt. Maybe add a
> > comment about the struct initialization needing to be visible before
> > pointer is set.
> 
> Is this clear?
> 
>          * release semantics on the initialization of the
>          * mmu_notifier_mm's contents are provided for unlocked readers.
> 	 * acquire can only be used while holding the
>          * mmgrab or mmget, and is safe because once created the
>          * mmu_notififer_mm is not freed until the mm is destroyed.
>          * Users holding the mmap_sem or one of the
> 	 * mm_take_all_locks() do not need to use acquire semantics.
> 
> It also helps explain why there is no locking around the other
> readers, which has puzzled me in the past at least.

Perfect.

Jérôme

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  reply	other threads:[~2019-10-21 19:47 UTC|newest]

Thread overview: 136+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-15 18:12 [PATCH hmm 00/15] Consolidate the mmu notifier interval_tree and locking Jason Gunthorpe
2019-10-15 18:12 ` Jason Gunthorpe
2019-10-15 18:12 ` [PATCH hmm 01/15] mm/mmu_notifier: define the header pre-processor parts even if disabled Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-21 18:32   ` Jerome Glisse
2019-10-21 18:32     ` Jerome Glisse
2019-10-15 18:12 ` [PATCH hmm 02/15] mm/mmu_notifier: add an interval tree notifier Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-21 18:30   ` Jerome Glisse
2019-10-21 18:30     ` Jerome Glisse
2019-10-21 18:54     ` Jason Gunthorpe
2019-10-21 18:54       ` Jason Gunthorpe
2019-10-21 19:11       ` Jerome Glisse
2019-10-21 19:11         ` Jerome Glisse
2019-10-21 19:24         ` Jason Gunthorpe
2019-10-21 19:24           ` Jason Gunthorpe
2019-10-21 19:47           ` Jerome Glisse [this message]
2019-10-21 19:47             ` Jerome Glisse
2019-10-27 23:15   ` Jason Gunthorpe
2019-10-27 23:15     ` Jason Gunthorpe
2019-10-27 23:15     ` Jason Gunthorpe
2019-10-15 18:12 ` [PATCH hmm 03/15] mm/hmm: allow hmm_range to be used with a mmu_range_notifier or hmm_mirror Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-21 18:33   ` Jerome Glisse
2019-10-21 18:33     ` Jerome Glisse
2019-10-15 18:12 ` [PATCH hmm 04/15] mm/hmm: define the pre-processor related parts of hmm.h even if disabled Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-21 18:31   ` Jerome Glisse
2019-10-21 18:31     ` Jerome Glisse
2019-10-15 18:12 ` [PATCH hmm 05/15] RDMA/odp: Use mmu_range_notifier_insert() Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-11-04 20:25   ` Jason Gunthorpe
2019-11-04 20:25     ` Jason Gunthorpe
2019-11-04 20:25     ` Jason Gunthorpe
2019-10-15 18:12 ` [PATCH hmm 06/15] RDMA/hfi1: Use mmu_range_notifier_inset for user_exp_rcv Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-29 12:15   ` Dennis Dalessandro
2019-10-29 12:15     ` Dennis Dalessandro
2019-10-29 12:15     ` Dennis Dalessandro
2019-10-15 18:12 ` [PATCH hmm 07/15] drm/radeon: use mmu_range_notifier_insert Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-15 18:12 ` [PATCH hmm 08/15] xen/gntdev: Use select for DMA_SHARED_BUFFER Jason Gunthorpe
2019-10-15 18:12   ` [Xen-devel] " Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-16  5:11   ` Jürgen Groß
2019-10-16  5:11     ` [Xen-devel] " Jürgen Groß
2019-10-16  5:11     ` Jürgen Groß
2019-10-16  6:35     ` Oleksandr Andrushchenko
2019-10-16  6:35       ` [Xen-devel] " Oleksandr Andrushchenko
2019-10-16  6:35       ` Oleksandr Andrushchenko
2019-10-21 19:12       ` Jason Gunthorpe
2019-10-21 19:12         ` [Xen-devel] " Jason Gunthorpe
2019-10-21 19:12         ` Jason Gunthorpe
2019-10-28  6:25         ` [Xen-devel] " Oleksandr Andrushchenko
2019-10-28  6:25           ` Oleksandr Andrushchenko
2019-10-28  6:25           ` Oleksandr Andrushchenko
2019-10-28  6:25           ` Oleksandr Andrushchenko
2019-10-28  6:25           ` Oleksandr Andrushchenko
2019-10-15 18:12 ` [PATCH hmm 09/15] xen/gntdev: use mmu_range_notifier_insert Jason Gunthorpe
2019-10-15 18:12   ` [Xen-devel] " Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-15 18:12 ` [PATCH hmm 10/15] nouveau: use mmu_notifier directly for invalidate_range_start Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-15 18:12 ` [PATCH hmm 11/15] nouveau: use mmu_range_notifier instead of hmm_mirror Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-15 18:12 ` [PATCH hmm 12/15] drm/amdgpu: Call find_vma under mmap_sem Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-15 18:12 ` [PATCH hmm 13/15] drm/amdgpu: Use mmu_range_insert instead of hmm_mirror Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-15 18:12 ` [PATCH hmm 14/15] drm/amdgpu: Use mmu_range_notifier " Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-15 18:12 ` [PATCH hmm 15/15] mm/hmm: remove hmm_mirror and related Jason Gunthorpe
2019-10-15 18:12   ` Jason Gunthorpe
2019-10-21 18:38   ` Jerome Glisse
2019-10-21 18:38     ` Jerome Glisse
2019-10-21 18:57     ` Jason Gunthorpe
2019-10-21 18:57       ` Jason Gunthorpe
2019-10-21 19:19       ` Jerome Glisse
2019-10-21 19:19         ` Jerome Glisse
2019-10-16  8:58 ` [PATCH hmm 00/15] Consolidate the mmu notifier interval_tree and locking Christian König
2019-10-16  8:58   ` Christian König
2019-10-16 16:04   ` Jason Gunthorpe
2019-10-16 16:04     ` Jason Gunthorpe
2019-10-17  8:54     ` Christian König
2019-10-17  8:54       ` Christian König
2019-10-17 16:26       ` Yang, Philip
2019-10-17 16:26         ` Yang, Philip
2019-10-17 16:47         ` Koenig, Christian
2019-10-17 16:47           ` Koenig, Christian
2019-10-18 20:36           ` Jason Gunthorpe
2019-10-18 20:36             ` Jason Gunthorpe
2019-10-20 14:21             ` Koenig, Christian
2019-10-20 14:21               ` Koenig, Christian
2019-10-21 13:57               ` Jason Gunthorpe
2019-10-21 13:57                 ` Jason Gunthorpe
2019-10-21 14:28                 ` Koenig, Christian
2019-10-21 14:28                   ` Koenig, Christian
2019-10-21 15:12                   ` Jason Gunthorpe
2019-10-21 15:12                     ` Jason Gunthorpe
2019-10-22  7:57                     ` Daniel Vetter
2019-10-22  7:57                       ` Daniel Vetter
2019-10-22 15:01                       ` Jason Gunthorpe
2019-10-22 15:01                         ` Jason Gunthorpe
2019-10-23  9:08                         ` Daniel Vetter
2019-10-23  9:08                           ` Daniel Vetter
2019-10-23  9:08                           ` Daniel Vetter
2019-10-23  9:32                           ` Christian König
2019-10-23  9:32                             ` Christian König
2019-10-23  9:32                             ` Christian König
2019-10-23 16:52                             ` Jerome Glisse
2019-10-23 16:52                               ` Jerome Glisse
2019-10-23 16:52                               ` Jerome Glisse
2019-10-23 16:52                               ` Jerome Glisse
2019-10-23 17:24                               ` Jason Gunthorpe
2019-10-23 17:24                                 ` Jason Gunthorpe
2019-10-23 17:24                                 ` Jason Gunthorpe
2019-10-23 17:24                                 ` Jason Gunthorpe
2019-10-24  2:16                                 ` Christoph Hellwig
2019-10-24  2:16                                   ` Christoph Hellwig
2019-10-24  2:16                                   ` Christoph Hellwig
2019-10-21 15:55 ` Dennis Dalessandro
2019-10-21 15:55   ` Dennis Dalessandro
2019-10-21 16:58   ` Jason Gunthorpe
2019-10-21 16:58     ` Jason Gunthorpe
2019-10-22 11:56     ` Dennis Dalessandro
2019-10-22 11:56       ` Dennis Dalessandro
2019-10-22 14:37       ` Jason Gunthorpe
2019-10-22 14:37         ` Jason Gunthorpe
2019-10-21 18:40 ` Jerome Glisse
2019-10-21 18:40   ` Jerome Glisse
2019-10-21 19:06   ` Jason Gunthorpe
2019-10-21 19:06     ` Jason Gunthorpe
2019-10-23 20:26     ` Jerome Glisse
2019-10-23 20:26       ` Jerome Glisse
2019-10-23 20:26       ` Jerome Glisse
2019-10-23 20:26       ` Jerome Glisse

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=20191021194748.GA5644@redhat.com \
    --to=jglisse@redhat.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=aarcange@redhat.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jgg@mellanox.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=rcampbell@nvidia.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.