e are going to need a lot more documentation on which flags are
"user" accessible vs not...
Reviewed-by: Ira Weiny
> Signed-off-by: John Hubbard
> ---
> drivers/infiniband/core/umem.c | 5 ++---
> drivers/infiniband/core/umem_odp.c | 10 +-
On Wed, Oct 30, 2019 at 03:49:16PM -0700, John Hubbard wrote:
> Introduce pin_user_pages*() variations of get_user_pages*() calls,
> and also pin_longterm_pages*() variations.
>
> These variants all set FOLL_PIN, which is also introduced, and
> basically documented. (An upcoming patch provides
On Thu, Oct 31, 2019 at 11:43:37AM -0700, John Hubbard wrote:
> On 10/31/19 11:35 AM, Ira Weiny wrote:
> > On Wed, Oct 30, 2019 at 03:49:13PM -0700, John Hubbard wrote:
> ...
> >> +
> >> +static void __remove_refs_from_head(struct page *page, int refs)
> >&
On Wed, Oct 30, 2019 at 03:49:14PM -0700, John Hubbard wrote:
> 1. Avoid naming conflicts: rename local static function from
> "pin_user_pages()" to "pin_goldfish_pages()".
>
> An upcoming patch will introduce a global pin_user_pages()
> function.
>
On Wed, Oct 30, 2019 at 03:49:13PM -0700, John Hubbard wrote:
> There are four locations in gup.c that have a fair amount of code
> duplication. This means that changing one requires making the same
> changes in four places, not to mention reading the same code four
> times, and wondering if there
On Wed, Oct 30, 2019 at 03:49:12PM -0700, John Hubbard wrote:
> A subsequent patch requires access to gup flags, so
> pass the flags argument through to the __gup_device_*
> functions.
>
> Also placate checkpatch.pl by shortening a nearby line.
>
Reviewed-by: Ira We
On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> > On Fri 02-08-19 12:14:09, John Hubbard wrote:
> > > On 8/2/19 7:52 AM, Jan Kara wrote:
> > > > On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> > > > > On Fri, Aug 02, 2019 at 02:41:46PM
equired.
>
> Reviewed-by: Christoph Hellwig
> Cc: Matthew Wilcox
> Cc: Jan Kara
> Cc: Ira Weiny
> Cc: Jason Gunthorpe
> Signed-off-by: John Hubbard
I assume this is superseded by the patch in the large series?
Ira
> ---
> drivers/infiniband/core/umem.c
equired.
>
> Reviewed-by: Christoph Hellwig
> Cc: Matthew Wilcox
> Cc: Jan Kara
> Cc: Ira Weiny
> Cc: Jason Gunthorpe
> Signed-off-by: John Hubbard
> ---
> drivers/infiniband/core/umem.c | 5 +-
> drivers/infiniband/hw/hfi1/user_pages.c
On Mon, Jul 22, 2019 at 09:41:34PM -0700, John Hubbard wrote:
> On 7/22/19 5:25 PM, Ira Weiny wrote:
> > On Mon, Jul 22, 2019 at 03:34:15PM -0700, john.hubb...@gmail.com wrote:
> > > From: John Hubbard
> > >
> > > For pages that were retained via get_user_pag
On Mon, Jul 22, 2019 at 03:34:15PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide
On Wed, Jun 26, 2019 at 02:27:16PM +0200, Christoph Hellwig wrote:
> The functionality is identical to the one currently open coded in
> p2pdma.c.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Ira Weiny
> ---
> drivers/pci/p2pdma.c | 57 ---
On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote:
> The functionality is identical to the one currently open coded in
> device-dax.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Ira Weiny
> ---
> drivers/dax/dax-private.h | 4
> drivers/d
TR(-EINVAL);
> + if (!pgmap->ref) {
> + if (pgmap->ops && (pgmap->ops->kill || pgmap->ops->cleanup))
> + return ERR_PTR(-EINVAL);
> +
> + init_completion(>done);
> + error = percpu_ref_init(>int
> pretty portable.
>
> Signed-off-by: Christoph Hellwig
Seems reasonable to me.
Reviewed-by: Ira Weiny
> ---
> drivers/gpu/drm/nouveau/Kconfig | 3 +--
> include/linux/hmm.h | 5 +
> include/linux/mm_types.h| 2 +-
> mm/
ny setups,
> and depend on it instead.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Ira Weiny
> ---
> drivers/gpu/drm/nouveau/Kconfig | 2 +-
> mm/Kconfig | 5 ++---
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/d
map using
> it.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Ira Weiny
> ---
> arch/powerpc/mm/mem.c | 10 +-
> arch/x86/mm/init_64.c | 8 ++--
> drivers/nvdimm/pfn_devs.c | 3 +--
> drivers/nvdimm/pmem.c | 1 -
> include/linux/memremap.h |
;
> +static atomic_t devmap_managed_enable;
> +
> +static void devmap_managed_enable_put(void *data)
> +{
> + if (atomic_dec_and_test(_managed_enable))
> + static_branch_disable(_managed_key);
> +}
> +
> +static int devmap_managed_enable_get(struct device *
On Wed, Jun 26, 2019 at 10:14:45AM -0700, 'Ira Weiny' wrote:
> On Wed, Jun 26, 2019 at 09:00:47AM -0700, Dan Williams wrote:
> > [ add Ira ]
> >
> > On Wed, Jun 26, 2019 at 5:27 AM Christoph Hellwig wrote:
> > >
> > > The code hasn't been used sinc
ice dax gets replaced with an explicit MEMORY_DEVICE_DEVDAX type.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Ira Weiny
> ---
> drivers/dax/device.c | 1 +
> include/linux/memremap.h | 8
> kernel/memremap.c| 22 ++
>
On Wed, Jun 26, 2019 at 09:00:47AM -0700, Dan Williams wrote:
> [ add Ira ]
>
> On Wed, Jun 26, 2019 at 5:27 AM Christoph Hellwig wrote:
> >
> > The code hasn't been used since it was added to the tree, and doesn't
> > appear to actually be usable.
> >
> > Signed-off-by: Christoph Hellwig
> >
On Thu, Jun 13, 2019 at 07:58:29PM +, Jason Gunthorpe wrote:
> On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell wrote:
> >
> > On 6/13/19 12:44 PM, Jason Gunthorpe wrote:
> > > On Thu, Jun 13, 2019 at 11:43:21AM +0200, Christoph Hellwig wrote:
> > > > The code hasn't been used since
On Thu, Jun 13, 2019 at 08:40:46PM +, Jason Gunthorpe wrote:
> On Thu, Jun 13, 2019 at 11:27:39AM -0700, Dan Williams wrote:
> > On Thu, Jun 13, 2019 at 2:43 AM Christoph Hellwig wrote:
> > >
> > > Hi Dan, Jérôme and Jason,
> > >
> > > below is a series that cleans up the dev_pagemap
On Thu, Jun 13, 2019 at 11:43:16AM +0200, Christoph Hellwig wrote:
> The functionality is identical to the one currently open coded in
> device-dax.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/dax/dax-private.h | 4 ---
> drivers/dax/device.c | 52
ructure is a
good simplification IMO. So...
Reviewed-by: Ira Weiny
> ---
>
> I'm sending this out now since we are updating many of the HMM APIs
> and I think it will be useful.
>
>
> drivers/gpu/drm/nouveau/nouveau_svm.c | 4 ++--
> include/linux/hmm.h
On Thu, Jun 06, 2019 at 03:44:37PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> This list is always read and written while holding hmm->lock so there is
> no need for the confusing _rcu annotations.
>
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jérôme G
+
> + /* The range is now invalid, leave it poisoned. */
> + range->valid = false;
No need to set valid false again as you just did this 5 lines above.
Reviewed-by: Ira Weiny
> + memset(>hmm, POISON_INUSE, sizeof(range->hmm));
> }
> EXPORT_SYMB
th.
> - A valid hmm has a valid hmm->mm.
>
> Allowing the return value of wait_event_timeout() (along with its internal
> barriers) to compute the result of the function.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Ira Weiny
> ---
> v3
> - Simplify the wait_
xchange pattern.
>
> Also make the locking very easy to understand by only ever reading or
> writing mm->hmm while holding the write side of the mmap_sem.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Ira Weiny
> ---
> v2:
> - Fix error unwind of mmgrab (Jerome)
>
t;
> Since mmdrop() (ie a 0 kref on struct mm) is now impossible with a !NULL
> mm->hmm delete the hmm_hmm_destroy().
>
> Signed-off-by: Jason Gunthorpe
> Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
> ---
> v2:
> - Fix error unwind paths in hmm_get_or_creat
> -
> /* Check if hmm_mm_destroy() was call. */
> - if (hmm->mm == NULL || hmm->dead) {
> - hmm_put(hmm);
> + if (hmm->mm == NULL || hmm->dead)
> return -EFAULT;
> - }
> +
> + range->hmm = hmm;
I don't think you
On Thu, Apr 11, 2019 at 08:41:30AM +0300, Leon Romanovsky wrote:
> On Wed, Apr 10, 2019 at 04:41:57PM -0700, Ira Weiny wrote:
> > On Tue, Mar 26, 2019 at 12:47:46PM -0400, Jerome Glisse wrote:
> > > From: Jérôme Glisse
> > >
[snip]
> > > diff --git a/include/
range->vma = vma;
> + range->event = event;
> range->mm = mm;
> range->start = start;
> range->end = end;
> - range->flags = 0;
> + range->flags = flags;
Which of the "user patch sets" uses the new flags?
On Tue, Feb 19, 2019 at 09:30:33PM -0800, 'Ira Weiny' wrote:
> From: Ira Weiny
>
> Resending these as I had only 1 minor comment which I believe we have covered
> in this series. I was anticipating these going through the mm tree as they
> depend on a cleanup patch there and
On Thu, Feb 21, 2019 at 08:48:41AM +0530, Souptick Joarder wrote:
> Hi Ira,
>
> On Wed, Feb 20, 2019 at 11:01 AM wrote:
> >
> > From: Ira Weiny
> >
> > To facilitate additional options to get_user_pages_fast() change the
> > singular write parameter t
On Wed, Feb 20, 2019 at 07:19:30AM -0800, Christoph Hellwig wrote:
> On Tue, Feb 19, 2019 at 09:30:33PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Resending these as I had only 1 minor comment which I believe we have
> > covered
> > in
From: Ira Weiny
To facilitate additional options to get_user_pages_fast() change the
singular write parameter to be gup_flags.
This patch does not change any functionality. New functionality will
follow in subsequent patches.
Some of the get_user_pages_fast() call sites were unchanged because
From: Ira Weiny
Rather than have a separate get_user_pages_longterm() call,
introduce FOLL_LONGTERM and change the longterm callers to use
it.
This patch does not change any functionality.
FOLL_LONGTERM can only be supported with get_user_pages() as it
requires vmas to determine if DAX
From: Ira Weiny
DAX pages were previously unprotected from longterm pins when users
called get_user_pages_fast().
Use the new FOLL_LONGTERM flag to check for DEVMAP pages and fall
back to regular GUP processing if a DEVMAP page is encountered.
Signed-off-by: Ira Weiny
---
mm/gup.c | 24
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/qib/qib_user_sdma.c
From: Ira Weiny
In order to support more options in the GUP fast walk, change
the write parameter to flags throughout the call stack.
This patch does not change functionality and passes FOLL_WRITE
where write was previously used.
Signed-off-by: Ira Weiny
---
mm/gup.c | 52
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/hfi1/user_pages.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/mthca/mthca_memfree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mthca
From: Ira Weiny
Resending these as I had only 1 minor comment which I believe we have covered
in this series. I was anticipating these going through the mm tree as they
depend on a cleanup patch there and the IB changes are very minor. But they
could just as well go through the IB tree.
NOTE
ange get_user_pages() to use the new FOLL_LONGTERM flag and
> remove the specialized get_user_pages_longterm call.
>
> [1] https://lkml.org/lkml/2019/2/11/237
> [2] https://lkml.org/lkml/2019/2/11/1789
Any comments on this series? I've touched a lot of subsystems which I think
require revi
On Wed, Feb 13, 2019 at 04:11:10PM -0700, Jason Gunthorpe wrote:
> On Wed, Feb 13, 2019 at 03:04:51PM -0800, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > To facilitate additional options to get_user_pages_fast() change the
> > singular write parameter to b
201 - 246 of 246 matches
Mail list logo
