From: Daniel Jordan <daniel.m.jordan@oracle.com>
To: Christopher Lameter <cl@linux.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
Daniel Jordan <daniel.m.jordan@oracle.com>,
jgg@ziepe.ca, akpm@linux-foundation.org, dave@stgolabs.net,
jack@suse.cz, linux-mm@kvack.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org,
alex.williamson@redhat.com, paulus@ozlabs.org,
benh@kernel.crashing.org, mpe@ellerman.id.au, hao.wu@intel.com,
atull@kernel.org, mdf@kernel.org
Subject: Re: [PATCH 2/5] vfio/spapr_tce: use pinned_vm instead of locked_vm to account pinned pages
Date: Tue, 12 Feb 2019 12:18:40 -0500 [thread overview]
Message-ID: <20190212171839.env4rnjwdjyips6z@ca-dmjordan1.us.oracle.com> (raw)
In-Reply-To: <01000168e29daf0a-cb3a9394-e3dd-4d88-ad3c-31df1f9ec052-000000@email.amazonses.com>
On Tue, Feb 12, 2019 at 04:50:11PM +0000, Christopher Lameter wrote:
> On Tue, 12 Feb 2019, Alexey Kardashevskiy wrote:
>
> > Now it is 3 independent accesses (actually 4 but the last one is
> > diagnostic) with no locking around them. Why do not we need a lock
> > anymore precisely? Thanks,
>
> Updating a regular counter is racy and requires a lock. It was converted
> to be an atomic which can be incremented without a race.
Yes, though Alexey may have meant that the multiple reads of the atomic in
decrement_pinned_vm are racy. It only matters when there's a bug that would
make the counter go negative, but it's there.
And FWIW the debug print in try_increment_pinned_vm is also racy.
This fixes all that. It doesn't try to correct the negative pinned_vm as the
old code did because it's already a bug and adjusting the value by the negative
amount seems to do nothing but make debugging harder.
If it's ok, I'll respin the whole series this way (another point for common
helper)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c b/drivers/vfio/vfio_iommu_spapr_tce.c
index f47e020dc5e4..b79257304de6 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -53,25 +53,24 @@ static long try_increment_pinned_vm(struct mm_struct *mm, long npages)
atomic64_sub(npages, &mm->pinned_vm);
}
- pr_debug("[%d] RLIMIT_MEMLOCK +%ld %ld/%lu%s\n", current->pid,
- npages << PAGE_SHIFT,
- atomic64_read(&mm->pinned_vm) << PAGE_SHIFT,
- rlimit(RLIMIT_MEMLOCK), ret ? " - exceeded" : "");
+ pr_debug("[%d] RLIMIT_MEMLOCK +%ld %lld/%lu%s\n", current->pid,
+ npages << PAGE_SHIFT, pinned << PAGE_SHIFT,
+ lock_limit, ret ? " - exceeded" : "");
return ret;
}
static void decrement_pinned_vm(struct mm_struct *mm, long npages)
{
+ s64 pinned;
+
if (!mm || !npages)
return;
- if (WARN_ON_ONCE(npages > atomic64_read(&mm->pinned_vm)))
- npages = atomic64_read(&mm->pinned_vm);
- atomic64_sub(npages, &mm->pinned_vm);
- pr_debug("[%d] RLIMIT_MEMLOCK -%ld %ld/%lu\n", current->pid,
- npages << PAGE_SHIFT,
- atomic64_read(&mm->pinned_vm) << PAGE_SHIFT,
+ pinned = atomic64_sub_return(npages, &mm->pinned_vm);
+ WARN_ON_ONCE(pinned < 0);
+ pr_debug("[%d] RLIMIT_MEMLOCK -%ld %lld/%lu\n", current->pid,
+ npages << PAGE_SHIFT, pinned << PAGE_SHIFT,
rlimit(RLIMIT_MEMLOCK));
}
next prev parent reply other threads:[~2019-02-12 17:18 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-11 22:44 [PATCH 0/5] " Daniel Jordan
2019-02-11 22:44 ` [PATCH 1/5] vfio/type1: " Daniel Jordan
2019-02-11 22:56 ` Jason Gunthorpe
2019-02-11 23:11 ` Daniel Jordan
2019-02-12 18:41 ` Alex Williamson
2019-02-13 0:26 ` Daniel Jordan
2019-02-13 20:03 ` Alex Williamson
2019-02-13 23:07 ` Jason Gunthorpe
2019-02-14 1:46 ` Daniel Jordan
2019-02-11 22:44 ` [PATCH 2/5] vfio/spapr_tce: " Daniel Jordan
2019-02-12 6:56 ` Alexey Kardashevskiy
2019-02-12 16:50 ` Christopher Lameter
2019-02-12 17:18 ` Daniel Jordan [this message]
2019-02-13 0:37 ` Alexey Kardashevskiy
2019-02-12 18:56 ` Alex Williamson
2019-02-13 0:34 ` Alexey Kardashevskiy
2019-02-11 22:44 ` [PATCH 3/5] fpga/dlf/afu: " Daniel Jordan
2019-02-11 22:44 ` [PATCH 4/5] powerpc/mmu: " Daniel Jordan
2019-02-13 1:14 ` kbuild test robot
2019-02-11 22:44 ` [PATCH 5/5] kvm/book3s: " Daniel Jordan
2019-02-13 1:43 ` kbuild test robot
2019-02-11 22:54 ` [PATCH 0/5] " Jason Gunthorpe
2019-02-11 23:15 ` Daniel Jordan
2019-02-14 1:53 ` Ira Weiny
2019-02-14 6:00 ` Jason Gunthorpe
2019-02-14 19:33 ` Ira Weiny
2019-02-14 20:12 ` Jason Gunthorpe
2019-02-14 21:46 ` Ira Weiny
2019-02-14 22:16 ` Jason Gunthorpe
2019-02-15 15:26 ` Christopher Lameter
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=20190212171839.env4rnjwdjyips6z@ca-dmjordan1.us.oracle.com \
--to=daniel.m.jordan@oracle.com \
--cc=aik@ozlabs.ru \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=atull@kernel.org \
--cc=benh@kernel.crashing.org \
--cc=cl@linux.com \
--cc=dave@stgolabs.net \
--cc=hao.wu@intel.com \
--cc=jack@suse.cz \
--cc=jgg@ziepe.ca \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mdf@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@ozlabs.org \
/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