[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190503232818.GA5182@mellanox.com>
Date: Fri, 3 May 2019 23:28:22 +0000
From: Jason Gunthorpe <jgg@...lanox.com>
To: Daniel Jordan <daniel.m.jordan@...cle.com>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
Alan Tull <atull@...nel.org>,
Alexey Kardashevskiy <aik@...abs.ru>,
Alex Williamson <alex.williamson@...hat.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Christoph Lameter <cl@...ux.com>,
Christophe Leroy <christophe.leroy@....fr>,
Davidlohr Bueso <dave@...olabs.net>,
Mark Rutland <mark.rutland@....com>,
Michael Ellerman <mpe@...erman.id.au>,
Moritz Fischer <mdf@...nel.org>,
Paul Mackerras <paulus@...abs.org>,
Steve Sistare <steven.sistare@...cle.com>,
Wu Hao <hao.wu@...el.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"kvm-ppc@...r.kernel.org" <kvm-ppc@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: add account_locked_vm utility function
On Fri, May 03, 2019 at 01:16:30PM -0700, Daniel Jordan wrote:
> locked_vm accounting is done roughly the same way in five places, so
> unify them in a helper. Standardize the debug prints, which vary
> slightly. Error codes stay the same, so user-visible behavior does too.
>
> Signed-off-by: Daniel Jordan <daniel.m.jordan@...cle.com>
> Cc: Alan Tull <atull@...nel.org>
> Cc: Alexey Kardashevskiy <aik@...abs.ru>
> Cc: Alex Williamson <alex.williamson@...hat.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>
> Cc: Christoph Lameter <cl@...ux.com>
> Cc: Christophe Leroy <christophe.leroy@....fr>
> Cc: Davidlohr Bueso <dave@...olabs.net>
> Cc: Jason Gunthorpe <jgg@...lanox.com>
> Cc: Mark Rutland <mark.rutland@....com>
> Cc: Michael Ellerman <mpe@...erman.id.au>
> Cc: Moritz Fischer <mdf@...nel.org>
> Cc: Paul Mackerras <paulus@...abs.org>
> Cc: Steve Sistare <steven.sistare@...cle.com>
> Cc: Wu Hao <hao.wu@...el.com>
> Cc: linux-mm@...ck.org
> Cc: kvm@...r.kernel.org
> Cc: kvm-ppc@...r.kernel.org
> Cc: linuxppc-dev@...ts.ozlabs.org
> Cc: linux-fpga@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
>
> Based on v5.1-rc7. Tested with the vfio type1 driver. Any feedback
> welcome.
>
> Andrew, this one patch replaces these six from [1]:
>
> mm-change-locked_vms-type-from-unsigned-long-to-atomic64_t.patch
> vfio-type1-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
> vfio-spapr_tce-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
> fpga-dlf-afu-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
> kvm-book3s-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
> powerpc-mmu-drop-mmap_sem-now-that-locked_vm-is-atomic.patch
>
> That series converts locked_vm to an atomic, but on closer inspection causes at
> least one accounting race in mremap, and fixing it just for this type
> conversion came with too much ugly in the core mm to justify, especially when
> the right long-term fix is making these drivers use pinned_vm instead.
Did we ever decide what to do here? Should all these drivers be
switched to pinned_vm anyhow?
Jason
Powered by blists - more mailing lists