From: Ralph Campbell
Update the HMM documentation to reflect the latest API and make a few
minor wording changes.
Cc: John Hubbard
Cc: Ira Weiny
Cc: Dan Williams
Cc: Arnd Bergmann
Cc: Balbir Singh
Cc: Dan Carpenter
Cc: Matthew Wilcox
Cc: Souptick Joarder
Cc: Andrew Morton
Signed-off-by:
ely.
Signed-off-by: Jason Gunthorpe
Reviewed-by: John Hubbard
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
include/linux/hmm.h | 26 --
mm/hmm.c| 32 +++-
2 files changed, 11 insertions(+),
ee.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Ira Weiny
Reviewed-by: John Hubbard
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
include/linux/hmm.h | 1 +
mm/hmm.c| 23 +--
2 files changed, 18 insertions(+), 6 deletions
-by: Ira Weiny
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
mm/hmm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 0423f4ca3a7e..73c8af4827fe 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -912,7 +912,7 @@ int hmm_range_register(str
From: Ralph Campbell
There are no functional changes, just some coding style clean ups and
minor comment changes.
Cc: John Hubbard
Cc: Ira Weiny
Cc: Dan Williams
Cc: Arnd Bergmann
Cc: Balbir Singh
Cc: Dan Carpenter
Cc: Matthew Wilcox
Cc: Souptick Joarder
Cc: Andrew Morton
Signed-off-by:
Hi Dan, Jérôme and Jason,
below is a series that cleans up the dev_pagemap interface so that
it is more easily usable, which removes the need to wrap it in hmm
and thus allowing to kill a lot of code
Note: this series is on top of Linux 5.2-rc6 and has some minor
conflicts with the hmm tree that
From: Jason Gunthorpe
gcc reports that several variables are defined but not used.
For the first hunk CONFIG_HUGETLB_PAGE the entire if block is already
protected by pud_huge() which is forced to 0. None of the stuff under the
ifdef causes compilation problems as it is already stubbed out in th
From: Philip Yang
While the page is migrating by NUMA balancing, HMM failed to detect this
condition and still return the old page. Application will use the new page
migrated, but driver pass the old page physical address to GPU, this crash
the application later.
Use pte_protnone(pte) to return
Checking range->valid is trivial and has no meaningful cost, but
nicely simplifies the fastpath in typical callers. Also remove the
hmm_vma_range_done function, which now is a trivial wrapper around
hmm_range_unregister.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouv
We should not have two different error codes for the same condition. In
addition this really complicates the code due to the special handling of
EAGAIN that drops the mmap_sem due to the FAULT_FLAG_ALLOW_RETRY logic
in the core vm.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 8 +++-
1
From: Jason Gunthorpe
Trying to misuse a range outside its lifetime is a kernel bug. Use poison
bytes to help detect this condition. Double unregister will reliably crash.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jérôme Glisse
Reviewed-by: John Hubbard
Acked-by: Souptick Joarder
Reviewed-
() (along with its internal
barriers) to compute the result of the function.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
Reviewed-by: John Hubbard
Reviewed-by: Ira Weiny
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
include/linux/hmm.h | 13 ++---
1 file c
.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index e831f4184a17..c0cf7aeaefb3 100644
--- a/drivers/gpu
From: Jason Gunthorpe
So we can check locking at runtime.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jérôme Glisse
Reviewed-by: John Hubbard
Reviewed-by: Ralph Campbell
Acked-by: Souptick Joarder
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
mm/hmm.c | 4 ++--
1 file
-by: Jason Gunthorpe
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
include/linux/hmm.h | 2 +-
mm/hmm.c| 69 ++---
2 files changed, 41 insertions(+), 30 deletions(-)
diff --git a/include/linux/hmm.
ops->release(mirror)
The only user we have today for ops->release is an empty function, so this
is unambiguously safe.
As a consequence of plugging this race drivers are not allowed to
register/unregister mirrors from within a release op.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Chris
Switch the one remaining user in nouveau over to its replacement,
and remove all the wrappers.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
include/linux/hmm.h| 36 --
2 files changed, 1 insertion(+), 37
hmm_vma_fault is marked as a legacy API to get rid of, but quite suites
the current nouvea flow. Move it to the only user in preparation for
fixing a locking bug involving caller and callee.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 54
Reviewed-by: John Hubbard
Reviewed-by: Ralph Campbell
Reviewed-by: Christoph Hellwig
Tested-by: Philip Yang
---
mm/hmm.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 6f5dc6d568fe..2ef14b2b5505 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -276,17
And I've demonstrated that I can't send patch series.. While this
has all the right patches, it also has the extra patches already
in the hmm tree, and four extra patches I wanted to send once
this series is merged. I'll give up for now, please use the git
url for anything serious, as it contains
On Tue, Jul 02, 2019 at 10:45:34PM +, Weiny, Ira wrote:
> >
> > On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > > And I've demonstrated that I can't send patch series.. While this has
> > > all the right patches, it also has th
On Wed, Jul 03, 2019 at 03:01:25PM -0300, Jason Gunthorpe wrote:
> Christoph, I guess you didn't mean to send this branch to the mailing
> list?
>
> In any event some of these, like this one, look obvious and I could
> still grab a few for hmm.git.
>
> Let me know what you'd like please
>
> Revi
On Wed, Jul 03, 2019 at 03:03:56PM -0300, Jason Gunthorpe wrote:
> I was thinking about doing exactly this too, but amdgpu started using
> this already obsolete API in their latest driver :(
>
> So, we now need to get both drivers to move to the modern API.
Actually the AMD folks fixed this up af
We should not have two different error codes for the same condition. In
addition this really complicates the code due to the special handling of
EAGAIN that drops the mmap_sem due to the FAULT_FLAG_ALLOW_RETRY logic
in the core vm.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
Checking range->valid is trivial and has no meaningful cost, but
nicely simplifies the fastpath in typical callers. Also remove the
hmm_vma_range_done function, which now is a trivial wrapper around
hmm_range_unregister.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
driv
.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index e831f4184a17..c0cf7aeaefb3 100644
--- a/drivers/gpu
Switch the one remaining user in nouveau over to its replacement,
and remove all the wrappers.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
include/linux/hmm.h| 34 --
2 files
hmm_vma_fault is marked as a legacy API to get rid of, but seems to suit
the current nouveau flow. Move it to the only user in preparation for
fixing a locking bug involving caller and callee.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which fixes up the mmap_sem
locking in nouveau and while at it also removes leftover legacy HMM APIs
only used by nouveau.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lis
On Wed, Jul 03, 2019 at 07:00:50PM +, Jason Gunthorpe wrote:
> I don't think the API should be encouraging some shortcut here..
>
> We can't do the above pattern because the old hmm_vma API didn't allow
> it, which is presumably a reason why it is obsolete.
>
> I'd rather see drivers move to
ittle less wrong and simpler.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index b9ced2e61667..a5d9b537c
On Wed, Jul 03, 2019 at 01:46:02PM -0700, Ralph Campbell wrote:
> You can delete the comment "With the old API the driver must ..."
> (not visible in the patch here).
Sure.
> I suggest moving the two assignments:
> range->default_flags = 0;
> range->pfn_flags_mask = -1UL;
> to just ab
Switch the one remaining user in nouveau over to its replacement,
and remove all the wrappers.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
include/linux/hmm.h| 34
.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 52 +-
include/linux/hmm.h | 63 ---
2 files changed, 50 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm
-EAGAIN has a magic meaning for non-blocking faults, so don't overload
it. Given that the caller doesn't check for specific error codes this
change is purely cosmetic.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
1 file changed, 1 insertion(+),
The parameter is always false, so remove it as well as the -EAGAIN
handling that can only happen for the non-blocking case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
We should not have two different error codes for the same condition. In
addition this really complicates the code due to the special handling of
EAGAIN that drops the mmap_sem due to the FAULT_FLAG_ALLOW_RETRY logic
in the core vm.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 9a9f71e4be29..d97d862e8b7d 100644
--- a/drivers/gpu/drm
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which fixes up the mmap_sem
locking in nouveau and while at it also removes leftover legacy HMM APIs
only used by nouveau.
Changes since v1:
- don't return the valid state from hmm_range_unregister
- additional nouveau cleanups
__
On Fri, Jul 05, 2019 at 09:33:36AM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 03, 2019 at 03:02:08PM -0700, Christoph Hellwig wrote:
> > Hi Jérôme, Ben and Jason,
> >
> > below is a series against the hmm tree which fixes up the mmap_sem
> > locking in nouveau a
We should not have two different error codes for the same condition. In
addition this really complicates the code due to the special handling of
EAGAIN that drops the mmap_sem due to the FAULT_FLAG_ALLOW_RETRY logic
in the core vm.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 45 +-
include/linux/hmm.h | 54 ---
2 files changed, 43 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm
Switch the one remaining user in nouveau over to its replacement,
and remove all the wrappers.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
include/linux/hmm.h| 34
-EAGAIN has a magic meaning for non-blocking faults, so don't overload
it. Given that the caller doesn't check for specific error codes this
change is purely cosmetic.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
1 file changed, 1 insertion(+),
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which fixes up the mmap_sem
locking in nouveau and while at it also removes leftover legacy HMM APIs
only used by nouveau.
The first 4 patches are a bug fix for nouveau, which I suspect should
go into this merge window even if the c
.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index 5dd83a46578f..5de2d54b9782 100644
--- a/drivers/gpu/drm
The parameter is always false, so remove it as well as the -EAGAIN
handling that can only happen for the non-blocking case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
On Tue, Jul 23, 2019 at 02:54:45PM +, Jason Gunthorpe wrote:
> I think without the commit message I wouldn't have been able to
> understand that, so Christoph, could you also add the comment below
> please?
I don't think this belongs into this patch. I can add it as a separate
patch under you
On Tue, Jul 23, 2019 at 02:56:24PM +, Jason Gunthorpe wrote:
> On Mon, Jul 22, 2019 at 11:44:23AM +0200, Christoph Hellwig wrote:
> > The parameter is always false, so remove it as well as the -EAGAIN
> > handling that can only happen for the non-blocking case.
>
> ? Di
On Tue, Jul 23, 2019 at 03:18:28PM +, Jason Gunthorpe wrote:
> Hum..
>
> The caller does this:
>
> again:
> ret = nouveau_range_fault(&svmm->mirror, &range);
> if (ret == 0) {
> mutex_lock(&svmm->mutex);
> if (!nouveau_ra
On Tue, Jul 23, 2019 at 03:27:41PM +, Jason Gunthorpe wrote:
> Ignoring the STAGING issue I've tried to use the same guideline as for
> -stable for -rc ..
>
> So this is a real problem, we definitely hit the locking bugs if we
> retry/etc under stress, so I would be OK to send it to Linus for
On Tue, Jul 23, 2019 at 02:17:31PM -0300, Jason Gunthorpe wrote:
> That reminds me, this code is also leaking hmm_range_unregister() in
> the success path, right?
No, that is done by hmm_vma_range_done / nouveau_range_done for the
success path.
>
> I think the right way to structure this is to m
.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 46 ++-
include/linux/hmm.h | 54 ---
2 files changed, 44 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which fixes up the mmap_sem
locking in nouveau and while at it also removes leftover legacy HMM APIs
only used by nouveau.
The first 4 patches are a bug fix for nouveau, which I suspect should
go into this merge window even if the c
The parameter is always false, so remove it as well as the -EAGAIN
handling that can only happen for the non-blocking case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm
We should not have two different error codes for the same condition. In
addition this really complicates the code due to the special handling of
EAGAIN that drops the mmap_sem due to the FAULT_FLAG_ALLOW_RETRY logic
in the core vm.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm/nouveau/nouveau_svm.c
index e3097492b4ad..a835cebb6d90 100644
--- a/drivers/gpu/drm
From: Jason Gunthorpe
The magic dropping of mmap_sem when handle_mm_fault returns
VM_FAULT_RETRY is rather subtile. Add a comment explaining it.
Signed-off-by: Jason Gunthorpe
[hch: wrote a changelog]
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 4 +++-
1 file changed, 3 insertions(+), 1
Switch the one remaining user in nouveau over to its replacement,
and remove all the wrappers.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
include/linux/hmm.h| 34
-EAGAIN has a magic meaning for non-blocking faults, so don't overload
it. Given that the caller doesn't check for specific error codes this
change is purely cosmetic.
Signed-off-by: Christoph Hellwig
Reviewed-by: Jason Gunthorpe
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 2
Looks good:
Reviewed-by: Christoph Hellwig
One comment on a related cleanup:
> list_for_each_entry(mirror, &hmm->mirrors, list) {
> int rc;
>
> - rc = mirror->ops->sync_cpu_device_pagetables(mirror, &update);
>
On Wed, Jul 24, 2019 at 12:28:58PM -0300, Jason Gunthorpe wrote:
> Humm. Actually having looked this some more, I wonder if this is a
> problem:
What a mess.
Question: do we even care for the non-blocking events? The only place
where mmu_notifier_invalidate_range_start_nonblock is called is the
On Wed, Jul 24, 2019 at 04:21:55PM -0300, Jason Gunthorpe wrote:
> If we change the register to keep the hlist sorted by address then we
> can do a targetted 'undo' of past starts terminated by address
> less-than comparison of the first failing struct mmu_notifier.
>
> It relies on the fact that
On Fri, Jul 26, 2019 at 12:16:30AM +, Jason Gunthorpe wrote:
> I don't see Ralph's tested by, do you think it changed enough to
> require testing again? If so, Ralph would you be so kind?
The changes were fairly small, but I didn't feel to carry it over given
that there were changes after all.
Note: it seems like you've only CCed me on patches 2-7, but not on the
cover letter and patch 1. I'll try to find them later, but to make Ccs
useful they should normally cover the whole series.
Otherwise this looks fine to me:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
> in hmm_vma_walk_pmd().
>
> Signed-off-by: Ralph Campbell
Looks good,
Reviewed-by: Christoph Hellwig
On Thu, Jul 25, 2019 at 05:56:50PM -0700, Ralph Campbell wrote:
> Since hmm_range_fault() doesn't use the struct hmm_range vma field,
> remove it.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Ralph Campbell
Looks good,
Reviewed-by: Christoph Hellwig
Factor out the repeated device memory address calculation into
a helper.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 42 +++---
1 file changed, 17 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers
When we start a new batch of dma_map operations we need to reset dma_nr,
as we start filling a newly allocated array.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers
code flow and error handling further on.
Signed-off-by: Christoph Hellwig
---
Documentation/vm/hmm.rst | 55 +-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 122 +++--
include/linux/migrate.h| 118 ++--
mm/migrate.c
We don't use this flag anymore, so remove it.
Signed-off-by: Christoph Hellwig
---
include/linux/migrate.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index 093d67fcf6dd..229153c2c496 100644
--- a/include/linux/migrate.h
+++ b/in
Factor out the end of fencing logic from the two migration routines.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 33 --
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu
ction makes it relatively easy to add multi page
support back if needed in the future. But at least for now this avoid
the needed to dynamically allocate memory for the dma addresses in
what is essentially the page fault path.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_d
work.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 185 -
1 file changed, 56 insertions(+), 129 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 036e6c07d489..6cb930755970 1
The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
where it can be replaced with a simple boolean local variable.
Signed-off-by: Christoph Hellwig
---
include/linux/migrate.h | 1 -
mm/migrate.c| 9 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff
No one ever checks this flag, and we could easily get that information
from the page if needed.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 +--
include/linux/migrate.h| 1 -
mm/migrate.c | 4 ++--
3 files changed, 3
Hi Jérôme, Ben and Jason,
below is a series against the hmm tree which starts revamping the
migrate_vma functionality. The prime idea is to export three slightly
lower level functions and thus avoid the need for migrate_vma_ops
callbacks.
Diffstat:
4 files changed, 285 insertions(+), 602 de
On Mon, Jul 29, 2019 at 07:30:44PM -0400, Jerome Glisse wrote:
> On Mon, Jul 29, 2019 at 05:28:43PM +0300, Christoph Hellwig wrote:
> > The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
> > where it can be replaced with a simple boolean local variable.
> &g
pte_index is an internal arch helper in various architectures,
without consistent semantics. Open code that calculation of a PMD
index based on the virtual address instead.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm
The start, end and page_shift values are all saved in the range
structure, so we might as well use that for argument passing.
Signed-off-by: Christoph Hellwig
---
Documentation/vm/hmm.rst| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +--
drivers/gpu/drm/nouveau
All users pass PAGE_SIZE here, and if we wanted to support single
entries for huge pages we should really just add a HMM_FAULT_HUGEPAGE
flag instead that uses the huge page size instead of having the
caller calculate that size once, just for the hmm code to verify it.
Signed-off-by: Christoph
The list is used to add the range to another list as an entry in the
core hmm code, so there is no need to initialize it in a driver.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu
Signed-off-by: Christoph Hellwig
---
include/linux/hmm.h | 1 -
mm/hmm.c| 2 --
2 files changed, 3 deletions(-)
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 82265118d94a..59be0aa2476d 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -422,7 +422,6 @@ long
Hi Jérôme, Ben, Felxi and Jason,
below is a series against the hmm tree which cleans up various minor
bits and allows HMM_MIRROR to be built on all architectures.
Diffstat:
7 files changed, 81 insertions(+), 171 deletions(-)
A git tree is also available at:
git://git.infradead.org/us
architectures when helpers like pud_pfn are not
implemented.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index e63ab7f11334..4d3bd41b6522 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
hmm_range_fault can only return -EAGAIN if called with the block
argument set to false, so remove the special handling for it.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git
This avoid having to abuse the vma field in struct hmm_range to unlock
the mmap_sem.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nouveau_svm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
b/drivers/gpu/drm
There isn't really any architecture specific code in this page table
walk implementation, so drop the dependencies.
Signed-off-by: Christoph Hellwig
---
mm/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index 56cec636a1fc..b18782b
Stub out the whole function when CONFIG_TRANSPARENT_HUGEPAGE is not set
to make the function easier to read.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 4d3bd41b6522..f4e90ea5779f
There is only a single place where the pgmap is passed over a function
call, so replace it with local variables in the places where we deal
with the pgmap.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 62
1 file changed, 27 insertions
The pagewalk code already passes the value as the hmask parameter.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index f26d6abc4ed2..88b77a4a6a1e 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -771,19
Stub out the whole function and assign NULL to the .hugetlb_entry method
if CONFIG_HUGETLB_PAGE is not set, as the method won't ever be called in
that case.
Signed-off-by: Christoph Hellwig
---
mm/hmm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/hmm.c
On Tue, Jul 30, 2019 at 12:32:24PM +, Jason Gunthorpe wrote:
> Does this only impact hmm users, or does migrate.c have a broader
> usage?
migrate.c really contains two things: the traditional page migration
code implementing aops ->migrate semantics, and migrate_vma and its
callbacks. The fi
On Tue, Jul 30, 2019 at 12:35:59PM +, Jason Gunthorpe wrote:
> On Tue, Jul 30, 2019 at 08:51:53AM +0300, Christoph Hellwig wrote:
> > This avoid having to abuse the vma field in struct hmm_range to unlock
> > the mmap_sem.
>
> I think the change inside hmm_range_fault g
On Tue, Jul 30, 2019 at 12:55:17PM +, Jason Gunthorpe wrote:
> I suspect this was added for the ODP conversion that does use both
> page sizes. I think the ODP code for this is kind of broken, but I
> haven't delved into that..
>
> The challenge is that the driver needs to know what page size
On Tue, Jul 30, 2019 at 01:14:58PM +, Jason Gunthorpe wrote:
> I have a patch deleting hmm->mm, so using svmm seems cleaner churn
> here, we could defer and I can fold this into that patch?
Sounds good. If I don't need to resend feel fee to fold it, otherwise
I'll fix it up.
_
On Tue, Jul 30, 2019 at 05:50:16PM +, Jason Gunthorpe wrote:
> The way ODP seems to work is once in hugetlb mode the dma addresses
> must give huge pages or the page fault will be failed. I think that is
> a terrible design, but this is how the driver is ..
>
> So, from this HMM perspective if
On Tue, Jul 30, 2019 at 05:53:14PM +, Jason Gunthorpe wrote:
> > - /* If THP is not enabled then we should never reach this
>
> This old comment says we should never get here
>
> > +}
> > +#else /* CONFIG_TRANSPARENT_HUGEPAGE */
> > +static int hmm_vma_handle_pmd(struct mm_walk *walk, unsi
On Tue, Jul 30, 2019 at 06:04:56PM +, Jason Gunthorpe wrote:
> Oh, can we make this into a non-user selectable option now?
>
> ie have the drivers that use the API select it?
Sure, I'll throw in another patch for that.
301 - 400 of 519 matches
Mail list logo