From: John Hubbard <jhubbard@nvidia.com>
To: <jglisse@redhat.com>, <linux-mm@kvack.org>
Cc: <linux-kernel@vger.kernel.org>,
Ralph Campbell <rcampbell@nvidia.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 01/10] mm/hmm: use reference counting for HMM struct
Date: Wed, 20 Feb 2019 15:47:50 -0800 [thread overview]
Message-ID: <1373673d-721e-a7a2-166f-244c16f236a3@nvidia.com> (raw)
In-Reply-To: <20190129165428.3931-2-jglisse@redhat.com>
On 1/29/19 8:54 AM, jglisse@redhat.com wrote:
> From: Jérôme Glisse <jglisse@redhat.com>
>
> Every time i read the code to check that the HMM structure does not
> vanish before it should thanks to the many lock protecting its removal
> i get a headache. Switch to reference counting instead it is much
> easier to follow and harder to break. This also remove some code that
> is no longer needed with refcounting.
Hi Jerome,
That is an excellent idea. Some review comments below:
[snip]
> static int hmm_invalidate_range_start(struct mmu_notifier *mn,
> const struct mmu_notifier_range *range)
> {
> struct hmm_update update;
> - struct hmm *hmm = range->mm->hmm;
> + struct hmm *hmm = hmm_get(range->mm);
> + int ret;
>
> VM_BUG_ON(!hmm);
>
> + /* Check if hmm_mm_destroy() was call. */
> + if (hmm->mm == NULL)
> + return 0;
Let's delete that NULL check. It can't provide true protection. If there
is a way for that to race, we need to take another look at refcounting.
Is there a need for mmgrab()/mmdrop(), to keep the mm around while HMM
is using it?
> +
> update.start = range->start;
> update.end = range->end;
> update.event = HMM_UPDATE_INVALIDATE;
> update.blockable = range->blockable;
> - return hmm_invalidate_range(hmm, true, &update);
> + ret = hmm_invalidate_range(hmm, true, &update);
> + hmm_put(hmm);
> + return ret;
> }
>
> static void hmm_invalidate_range_end(struct mmu_notifier *mn,
> const struct mmu_notifier_range *range)
> {
> struct hmm_update update;
> - struct hmm *hmm = range->mm->hmm;
> + struct hmm *hmm = hmm_get(range->mm);
>
> VM_BUG_ON(!hmm);
>
> + /* Check if hmm_mm_destroy() was call. */
> + if (hmm->mm == NULL)
> + return;
> +
Another one to delete, same reasoning as above.
[snip]
> @@ -717,14 +746,18 @@ int hmm_vma_get_pfns(struct hmm_range *range)
> hmm = hmm_register(vma->vm_mm);
> if (!hmm)
> return -ENOMEM;
> - /* Caller must have registered a mirror, via hmm_mirror_register() ! */
> - if (!hmm->mmu_notifier.ops)
> +
> + /* Check if hmm_mm_destroy() was call. */
> + if (hmm->mm == NULL) {
> + hmm_put(hmm);
> return -EINVAL;
> + }
>
Another hmm->mm NULL check to remove.
[snip]
> @@ -802,25 +842,27 @@ EXPORT_SYMBOL(hmm_vma_get_pfns);
> */
> bool hmm_vma_range_done(struct hmm_range *range)
> {
> - unsigned long npages = (range->end - range->start) >> PAGE_SHIFT;
> - struct hmm *hmm;
> + bool ret = false;
>
> - if (range->end <= range->start) {
> + /* Sanity check this really should not happen. */
> + if (range->hmm == NULL || range->end <= range->start) {
> BUG();
> return false;
> }
>
> - hmm = hmm_register(range->vma->vm_mm);
> - if (!hmm) {
> - memset(range->pfns, 0, sizeof(*range->pfns) * npages);
> - return false;
> - }
> -
> - spin_lock(&hmm->lock);
> + spin_lock(&range->hmm->lock);
> list_del_rcu(&range->list);
> - spin_unlock(&hmm->lock);
> + ret = range->valid;
> + spin_unlock(&range->hmm->lock);
>
> - return range->valid;
> + /* Is the mm still alive ? */
> + if (range->hmm->mm == NULL)
> + ret = false;
And another one here.
> +
> + /* Drop reference taken by hmm_vma_fault() or hmm_vma_get_pfns() */
> + hmm_put(range->hmm);
> + range->hmm = NULL;
> + return ret;
> }
> EXPORT_SYMBOL(hmm_vma_range_done);
>
> @@ -880,6 +922,8 @@ int hmm_vma_fault(struct hmm_range *range, bool block)
> struct hmm *hmm;
> int ret;
>
> + range->hmm = NULL;
> +
> /* Sanity check, this really should not happen ! */
> if (range->start < vma->vm_start || range->start >= vma->vm_end)
> return -EINVAL;
> @@ -891,14 +935,18 @@ int hmm_vma_fault(struct hmm_range *range, bool block)
> hmm_pfns_clear(range, range->pfns, range->start, range->end);
> return -ENOMEM;
> }
> - /* Caller must have registered a mirror using hmm_mirror_register() */
> - if (!hmm->mmu_notifier.ops)
> +
> + /* Check if hmm_mm_destroy() was call. */
> + if (hmm->mm == NULL) {
> + hmm_put(hmm);
> return -EINVAL;
> + }
And here.
>
> /* FIXME support hugetlb fs */
> if (is_vm_hugetlb_page(vma) || (vma->vm_flags & VM_SPECIAL) ||
> vma_is_dax(vma)) {
> hmm_pfns_special(range);
> + hmm_put(hmm);
> return -EINVAL;
> }
>
> @@ -910,6 +958,7 @@ int hmm_vma_fault(struct hmm_range *range, bool block)
> * operations such has atomic access would not work.
> */
> hmm_pfns_clear(range, range->pfns, range->start, range->end);
> + hmm_put(hmm);
> return -EPERM;
> }
>
> @@ -945,7 +994,16 @@ int hmm_vma_fault(struct hmm_range *range, bool block)
> hmm_pfns_clear(range, &range->pfns[i], hmm_vma_walk.last,
> range->end);
> hmm_vma_range_done(range);
> + hmm_put(hmm);
> + } else {
> + /*
> + * Transfer hmm reference to the range struct it will be drop
> + * inside the hmm_vma_range_done() function (which _must_ be
> + * call if this function return 0).
> + */
> + range->hmm = hmm;
Is that thread-safe? Is there anything preventing two or more threads from
changing range->hmm at the same time?
thanks,
--
John Hubbard
NVIDIA
next prev parent reply other threads:[~2019-02-20 23:48 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-29 16:54 [PATCH 00/10] HMM updates for 5.1 jglisse
2019-01-29 16:54 ` [PATCH 01/10] mm/hmm: use reference counting for HMM struct jglisse
2019-02-20 23:47 ` John Hubbard [this message]
2019-02-20 23:59 ` Jerome Glisse
2019-02-21 0:06 ` John Hubbard
2019-02-21 0:15 ` Jerome Glisse
2019-02-21 0:32 ` John Hubbard
2019-02-21 0:37 ` Jerome Glisse
2019-02-21 0:42 ` John Hubbard
2019-01-29 16:54 ` [PATCH 02/10] mm/hmm: do not erase snapshot when a range is invalidated jglisse
2019-02-20 23:58 ` John Hubbard
2019-01-29 16:54 ` [PATCH 03/10] mm/hmm: improve and rename hmm_vma_get_pfns() to hmm_range_snapshot() jglisse
2019-02-21 0:25 ` John Hubbard
2019-02-21 0:28 ` Jerome Glisse
2019-01-29 16:54 ` [PATCH 04/10] mm/hmm: improve and rename hmm_vma_fault() to hmm_range_fault() jglisse
2019-01-29 16:54 ` [PATCH 05/10] mm/hmm: improve driver API to work and wait over a range jglisse
2019-01-29 16:54 ` [PATCH 06/10] mm/hmm: add default fault flags to avoid the need to pre-fill pfns arrays jglisse
2019-01-29 16:54 ` [PATCH 07/10] mm/hmm: add an helper function that fault pages and map them to a device jglisse
2019-03-18 20:21 ` Dan Williams
2019-03-18 20:41 ` Jerome Glisse
2019-03-18 21:30 ` Dan Williams
2019-03-18 22:15 ` Jerome Glisse
2019-03-19 3:29 ` Dan Williams
2019-03-19 13:30 ` Jerome Glisse
2019-03-19 8:44 ` Ira Weiny
2019-03-19 17:10 ` Jerome Glisse
2019-03-19 14:10 ` Ira Weiny
2019-01-29 16:54 ` [PATCH 08/10] mm/hmm: support hugetlbfs (snap shoting, faulting and DMA mapping) jglisse
2019-01-29 16:54 ` [PATCH 09/10] mm/hmm: allow to mirror vma of a file on a DAX backed filesystem jglisse
2019-01-29 18:41 ` Dan Williams
2019-01-29 19:31 ` Jerome Glisse
2019-01-29 20:51 ` Dan Williams
2019-01-29 21:21 ` Jerome Glisse
2019-01-30 2:32 ` Dan Williams
2019-01-30 3:03 ` Jerome Glisse
2019-01-30 17:25 ` Dan Williams
2019-01-30 18:36 ` Jerome Glisse
2019-01-31 3:28 ` Dan Williams
2019-01-31 4:16 ` Jerome Glisse
2019-01-31 5:44 ` Dan Williams
2019-03-05 22:16 ` Andrew Morton
2019-03-06 4:20 ` Dan Williams
2019-03-06 15:51 ` Jerome Glisse
2019-03-06 15:57 ` Dan Williams
2019-03-06 16:03 ` Jerome Glisse
2019-03-06 16:06 ` Dan Williams
2019-03-07 17:46 ` Andrew Morton
2019-03-07 18:56 ` Jerome Glisse
2019-03-12 3:13 ` Dan Williams
2019-03-12 15:25 ` Jerome Glisse
2019-03-12 16:06 ` Dan Williams
2019-03-12 19:06 ` Jerome Glisse
2019-03-12 19:30 ` Dan Williams
2019-03-12 20:34 ` Dave Chinner
2019-03-13 1:06 ` Dan Williams
2019-03-12 21:52 ` Andrew Morton
2019-03-13 0:10 ` Jerome Glisse
2019-03-13 0:46 ` Dan Williams
2019-03-13 1:00 ` Jerome Glisse
2019-03-13 16:06 ` Andrew Morton
2019-03-13 18:39 ` Jerome Glisse
2019-03-06 15:49 ` Jerome Glisse
2019-03-06 22:18 ` Andrew Morton
2019-03-07 0:36 ` Jerome Glisse
2019-01-29 16:54 ` [PATCH 10/10] mm/hmm: add helpers for driver to safely take the mmap_sem jglisse
2019-02-20 21:59 ` John Hubbard
2019-02-20 22:19 ` Jerome Glisse
2019-02-20 22:40 ` John Hubbard
2019-02-20 23:09 ` Jerome Glisse
2019-02-20 23:17 ` [PATCH 00/10] HMM updates for 5.1 John Hubbard
2019-02-20 23:36 ` Jerome Glisse
2019-02-22 23:31 ` Ralph Campbell
2019-03-13 1:27 ` Jerome Glisse
2019-03-13 16:10 ` Andrew Morton
2019-03-13 18:01 ` Jason Gunthorpe
2019-03-13 18:33 ` Jerome Glisse
2019-03-18 17:00 ` Kuehling, Felix
2019-03-18 17:04 ` Jerome Glisse
2019-03-18 18:30 ` Dan Williams
2019-03-18 18:54 ` Jerome Glisse
2019-03-18 19:18 ` Dan Williams
2019-03-18 19:28 ` Jerome Glisse
2019-03-18 19:36 ` Dan Williams
2019-03-19 16:40 ` Andrew Morton
2019-03-19 16:58 ` Jerome Glisse
2019-03-19 17:12 ` Andrew Morton
2019-03-19 17:18 ` Jerome Glisse
2019-03-19 17:33 ` Dan Williams
2019-03-19 17:45 ` Jerome Glisse
2019-03-19 18:42 ` Dan Williams
2019-03-19 19:05 ` Jerome Glisse
2019-03-19 19:13 ` Dan Williams
2019-03-19 14:18 ` Ira Weiny
2019-03-19 22:24 ` Jerome Glisse
2019-03-19 19:18 ` Jerome Glisse
2019-03-19 20:25 ` Jerome Glisse
2019-03-19 21:51 ` Stephen Rothwell
2019-03-19 18:51 ` Deucher, Alexander
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=1373673d-721e-a7a2-166f-244c16f236a3@nvidia.com \
--to=jhubbard@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=jglisse@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox