On Thu, May 30, 2019 at 11:31:12PM +0800, Yuehaibing wrote:
> Hi all,
>
> Friendly ping:
>
> Who can take this?
>
> On 2019/4/17 22:26, Yue Haibing wrote:
> > From: YueHaibing
> >
> > During randconfig builds, I occasionally run into an invalid configuration
> >
> > WARNING: unmet direct
On Tue, Jun 25, 2019 at 09:29:15AM +0200, Christoph Hellwig wrote:
> On Thu, Jun 20, 2019 at 09:26:48PM +0200, Michal Hocko wrote:
> > On Thu 13-06-19 11:43:21, Christoph Hellwig wrote:
> > > The code hasn't been used since it was added to the tree, and doesn't
> > > appear to actually be usable.
On Thu, Jun 13, 2019 at 11:43:03AM +0200, Christoph Hellwig wrote:
> 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
Do you want some of
quest_mem_region(dev, addr, size, dev_name(dev));
> + if (!res)
> + return ERR_PTR(-ENOMEM);
> + res->desc = IORES_DESC_DEVICE_PRIVATE_MEMORY;
I wonder if IORES_DESC_DEVICE_PRIVATE_MEMORY should be a function
argument?
Not really any substantive remark, so
Reviewed-by: Jason Gunthorpe
Jason
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
tic void dev_dax_percpu_kill(struct percpu_ref *data)
> +static void dev_dax_percpu_kill(struct dev_pagemap *pgmap)
> {
Looks like it was always like this, but I also can't see a reason to
use the percpu as a handle for a dev_pagemap callback.
Reviewed-by: Jason Gunthorpe
Jason
On Thu, Jun 13, 2019 at 11:43:23AM +0200, Christoph Hellwig wrote:
> The ZONE_DEVICE support doesn't depend on anything HMM related, just on
> various bits of arch support as indicated by the architecture. Also
> don't select the option from nouveau as it isn't present in many setups,
> and
On Thu, Jun 13, 2019 at 11:43:12AM +0200, Christoph Hellwig wrote:
> Just check if there is a ->page_free operation set and take care of the
> static key enable, as well as the put using device managed resources.
> diff --git a/mm/hmm.c b/mm/hmm.c
> index c76a1b5defda..6dc769feb2e1 100644
> +++
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 it was added to the tree, and doesn't
> > >
ivers/gpu/drm/nouveau/Kconfig | 1 +
> mm/Kconfig | 1 -
> 2 files changed, 1 insertion(+), 1 deletion(-)
Yes, the thing that calls migrate_vma() should be the thing that has
the kconfig stuff.
Reviewed-by: Jason Gunthorpe
Jason
_
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 interface so that
> > it is more easily usable, which removes the need to wrap it in
-
> include/linux/memremap.h | 3 +--
> kernel/memremap.c| 2 +-
> mm/hmm.c | 9 +
> 4 files changed, 8 insertions(+), 8 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
.c | 115 --
> 3 files changed, 270 deletions(-)
I looked for in-flight patches that might be using these APIs and
found nothing. To be sent patches can use the new API with no loss in
functionality...
Reviewed-
On Thu, Jun 13, 2019 at 11:43:24AM +0200, Christoph Hellwig wrote:
> All the mm/hmm.c code is better keyed off HMM_MIRROR. Also let nouveau
> depend on it instead of the mix of a dummy dependency symbol plus the
> actually selected one. Drop various odd dependencies, as the code is
> pretty
On Thu, Jun 13, 2019 at 11:43:10AM +0200, Christoph Hellwig wrote:
> The dev_pagemap is a growing too many callbacks. Move them into a
> separate ops structure so that they are not duplicated for multiple
> instances, and an attacker can't easily overwrite them.
Reviewed-by: Jason
d, 2 insertions(+), 1 deletion(-)
Reviewed-by: Jason Gunthorpe
Jason
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Thu, Jun 13, 2019 at 11:43:21AM +0200, Christoph Hellwig wrote:
> The code hasn't been used since it was added to the tree, and doesn't
> appear to actually be usable. Mark it as BROKEN until either a user
> comes along or we finally give up on it.
>
> Signed-off-by: Christoph Hellwig
>
rd 'hmm_deviceX' name, without also defining a
core kernel ABI for that char dev..
If this comes back it needs a proper explanation and review, with a
user.
Reviewed-by: Jason Gunthorpe
Jason
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https:/
iver to call devm_memremap_pages(),
maybe even with all this boiler plate, in future.
If we eventually get many users that need some simplified registration
then we should add a devm_memremap_pages_simplified() interface and
factor out that code when we can see the pattern.
Reviewed-by: Jason Gunth
ed the crazy process described in the commit message
that (deliberately) introduced this unused kconfig.
I also tried to find something in-flight for 5.3 that would need this
and found nothing
Reviewed-by: Jason Gunthorpe
Jason
to start using mapping then the driver
should be responsible to set it back to NULL before being done with
the page.
Reviewed-by: Jason Gunthorpe
Jason
On Thu, Jun 13, 2019 at 05:11:21PM -0700, Ralph Campbell wrote:
> In nouveau_dmem_pages_alloc(), the drm->dmem->mutex is unlocked before
> calling nouveau_dmem_chunk_alloc().
> Reacquire the lock before continuing to the next page.
>
> Signed-off-by: Ralph Campbell
> ---
>
> I found this while
On Wed, Jun 19, 2019 at 11:40:32AM +0200, Christoph Hellwig wrote:
> On Tue, Jun 18, 2019 at 12:47:10PM -0700, Dan Williams wrote:
> > > Git tree:
> > >
> > > git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup.2
> > >
> > > Gitweb:
> > >
> > >
> > >
On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
> On 6/13/19 5:43 PM, Ira Weiny wrote:
> > On Thu, Jun 13, 2019 at 07:58:29PM +0000, Jason Gunthorpe wrote:
> >> On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell wrote:
> >>>
> ...
> >&g
On Wed, Jun 19, 2019 at 09:46:23AM -0700, Dan Williams wrote:
> On Wed, Jun 19, 2019 at 9:37 AM Jason Gunthorpe wrote:
> >
> > On Wed, Jun 19, 2019 at 11:40:32AM +0200, Christoph Hellwig wrote:
> > > On Tue, Jun 18, 2019 at 12:47:10PM -0700, Dan Williams w
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 and while at it also removes leftover legacy HMM APIs
> only used by nouveau.
>
> Changes since v1:
> -
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 and while at it also removes leftover legacy HMM APIs
> only used by nouveau.
As much as I like this series,
3 ---
> mm/hmm.c| 14 --
> 2 files changed, 17 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
--
> mm/memory.c | 9 ++---
> 6 files changed, 17 insertions(+), 67 deletions(-)
Reviewed-by: Jason Gunthorpe
I'ver heard there are some other use models for fault() here beyond
migrate to ram, but we can rename it if we ever see them.
> +static vm_fault_
le | 2 +-
> mm/hmm.c| 2 --
> 6 files changed, 8 insertions(+), 33 deletions(-)
Makes more sense to me too
Reviewed-by: Jason Gunthorpe
Jason
map_pages
> directly.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Jason Gunthorpe
> Reviewed-by: John Hubbard
> Acked-by: Michal Hocko
> ---
> include/linux/hmm.h | 3 ---
> mm/hmm.c| 50 -
> 2 file
On Mon, Jul 01, 2019 at 08:20:18AM +0200, Christoph Hellwig wrote:
> 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
hat you'd like please
Reviewed-by: Jason Gunthorpe
Thanks,
Jason
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Wed, Jul 03, 2019 at 08:03:08PM +0200, Christoph Hellwig wrote:
> 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 on
On Wed, Jul 03, 2019 at 11:44:58AM -0700, Christoph Hellwig wrote:
> Checking range->valid is trivial and has no meaningful cost, but
> nicely simplifies the fastpath in typical callers.
It should not be the typical caller..
> hmm_vma_range_done function, which now is a trivial wrapper around
On Wed, Jul 03, 2019 at 08:05:25PM +0200, Christoph Hellwig wrote:
> 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 :(
> >
>
On Wed, Jul 03, 2019 at 10:28:57PM +0200, Christoph Hellwig wrote:
> On Wed, Jul 03, 2019 at 07:00:50PM +0000, 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'
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 the extra patches already
> in the hmm tree, and four extra patches I wanted to send once
> this series is merged. I'll
On Tue, Jul 02, 2019 at 04:17:48PM -0700, Dan Williams wrote:
> On Tue, Jul 2, 2019 at 11:42 AM Jason Gunthorpe 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
On Mon, Jul 08, 2019 at 10:30:55AM -0700, Ralph Campbell wrote:
>
> On 7/4/19 9:42 AM, 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 t
On Fri, Jun 28, 2019 at 10:10:12AM -0700, Dan Williams wrote:
> On Fri, Jun 28, 2019 at 10:08 AM Dan Williams
> wrote:
> >
> > On Fri, Jun 28, 2019 at 10:02 AM Jason Gunthorpe wrote:
> > >
> > > On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote:
On Fri, Jun 28, 2019 at 09:27:44AM -0700, Dan Williams wrote:
> On Fri, Jun 28, 2019 at 8:39 AM Jason Gunthorpe wrote:
> >
> > On Wed, Jun 26, 2019 at 02:27:15PM +0200, Christoph Hellwig wrote:
> > > The functionality is identical to the one currently open c
On Fri, Aug 16, 2019 at 06:44:48AM +0200, Christoph Hellwig wrote:
> On Fri, Aug 16, 2019 at 12:43:07AM +0000, Jason Gunthorpe wrote:
> > On Thu, Aug 15, 2019 at 04:51:33PM -0400, Jerome Glisse wrote:
> >
> > > struct page. In this case any way we can update the
> >
gt; ---
> drivers/gpu/drm/nouveau/Kconfig | 1 -
> mm/Kconfig | 3 ---
> mm/migrate.c| 4 ++--
> 3 files changed, 2 insertions(+), 6 deletions(-)
Reviewed-by: Jason Gunthorpe
Aside from it making sense, I checked no other driver enable
On Thu, Aug 15, 2019 at 08:54:46PM -0700, Dan Williams wrote:
> > However, this means we cannot do any processing of ZONE_DEVICE pages
> > outside the driver lock, so eg, doing any DMA map that might rely on
> > MEMORY_DEVICE_PCI_P2PDMA has to be done in the driver lock, which is
> > a bit
On Fri, Aug 16, 2019 at 08:51:41AM +0200, Christoph Hellwig wrote:
> Jason,
>
> are you going to look into picking this up? Unfortunately there is
> a hole pile in this area still pending, including the kvmppc secure
> memory driver from Bharata that depends on the work.
>
> mm folks:
au/nouveau_dmem.c | 3 +--
> include/linux/migrate.h| 1 -
> mm/migrate.c | 4 ++--
> 3 files changed, 3 insertions(+), 5 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
Nouveau mailing list
Nouve
low nits in,
let me know if I got it wrong
Reviewed-by: Jason Gunthorpe
diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst
index 4f81c77059e305..0a5960beccf76d 100644
--- a/Documentation/vm/hmm.rst
+++ b/Documentation/vm/hmm.rst
@@ -339,9 +33
On Wed, Aug 14, 2019 at 09:59:18AM +0200, Christoph Hellwig wrote:
> 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
On Fri, Aug 16, 2019 at 08:51:41AM +0200, Christoph Hellwig wrote:
> Jason,
>
> are you going to look into picking this up? Unfortunately there is
> a hole pile in this area still pending, including the kvmppc secure
> memory driver from Bharata that depends on the work.
Done,
Lets see if Dan
On Fri, Aug 16, 2019 at 10:21:41AM -0700, Dan Williams wrote:
> > We can do a get_dev_pagemap inside the page_walk and touch the pgmap,
> > or we can do the 'device mutex && retry' pattern and touch the pgmap
> > in the driver, under that lock.
> >
> > However in all cases the current
On Sat, Aug 17, 2019 at 01:31:28PM +0200, Christoph Hellwig wrote:
> On Fri, Aug 16, 2019 at 05:11:07PM +0000, Jason Gunthorpe wrote:
> > - if (args->cpages)
> > - migrate_vma_prepare(args);
> > - if (args->cpages)
> > - migrate_vma_unmap
On Thu, Aug 15, 2019 at 02:03:25PM -0400, Jerome Glisse wrote:
> On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote:
> > >
> > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote:
&
On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
> So nor HMM nor driver should dereference the struct page (i do not
> think any iommu driver would either),
Er, they do technically deref the struct page:
nouveau_dmem_convert_pfn(struct nouveau_drm *drm,
On Thu, Aug 15, 2019 at 01:47:12PM -0700, Dan Williams wrote:
> On Thu, Aug 15, 2019 at 1:41 PM Jason Gunthorpe wrote:
> >
> > On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
> >
> > > So nor HMM nor driver should dereference the struct page (i do no
On Thu, Aug 15, 2019 at 04:51:33PM -0400, Jerome Glisse wrote:
> struct page. In this case any way we can update the
> nouveau_dmem_page() to check that page page->pgmap == the
> expected pgmap.
I was also wondering if that is a problem.. just blindly doing a
container_of on the page->pgmap does
On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote:
> On Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan Williams wrote:
> > Section alignment constraints somewhat save us here. The only example
> > I can think of a PMD not containing a uniform pgmap association for
> > each pte is the
On Mon, Aug 26, 2019 at 11:02:12AM -0700, Ralph Campbell wrote:
>
> On 8/24/19 3:37 PM, Christoph Hellwig wrote:
> > On Fri, Aug 23, 2019 at 03:17:52PM -0700, Ralph Campbell wrote:
> > > Although hmm_range_fault() calls find_vma() to make sure that a vma exists
> > > before calling
On Tue, Aug 27, 2019 at 01:16:13PM -0700, Ralph Campbell wrote:
>
> On 8/27/19 11:41 AM, Jason Gunthorpe wrote:
> > On Fri, Aug 23, 2019 at 03:17:53PM -0700, Ralph Campbell wrote:
> >
> > > Signed-off-by: Ralph Campbell
> > > mm/hmm.c | 3 +++
On Fri, Aug 23, 2019 at 03:17:51PM -0700, Ralph Campbell wrote:
> I have been working on converting Jerome's hmm_dummy driver and self
> tests into a stand-alone set of tests to be included in
> tools/testing/selftests/vm and came across these two bug fixes in the
> process. The tests aren't quite
On Fri, Aug 23, 2019 at 03:17:53PM -0700, Ralph Campbell wrote:
> Signed-off-by: Ralph Campbell
> mm/hmm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 29371485fe94..4882b83aeccb 100644
> +++ b/mm/hmm.c
> @@ -292,6 +292,9 @@ static int
On Tue, Jul 30, 2019 at 03:10:38PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 30, 2019 at 12:35:59PM +0000, 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 h
On Tue, Jul 30, 2019 at 08:51:55AM +0300, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> include/linux/hmm.h | 1 -
> mm/hmm.c| 2 --
> 2 files changed, 3 deletions(-)
Reviewed-by: Jason Gunthorpe
Unclear what this was intended for, but I think if we n
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 got lost on rebase, it is
now using:
up_read(>hmm->mm->mmap_sem);
But, yes, lets
On Tue, Jul 30, 2019 at 08:51:57AM +0300, Christoph Hellwig wrote:
> 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
dgpu_ttm.c | 23 +++
> 1 file changed, 3 insertions(+), 20 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Mon, Jul 29, 2019 at 05:28:34PM +0300, Christoph Hellwig wrote:
> 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
pu/amdgpu_mn.c | 1 -
> 1 file changed, 1 deletion(-)
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Jul 30, 2019 at 03:03:46PM -0300, Jason Gunthorpe wrote:
> On Tue, Jul 30, 2019 at 08:52:03AM +0300, Christoph Hellwig wrote:
> > There isn't really any architecture specific code in this page table
> > walk implementation, so drop the dependencies.
> >
> &g
on(+), 2 deletions(-)
Happy to see it, lets try to get this patch + the required parts of
this series into linux-next to be really sure
Reviewed-by: Jason Gunthorpe
Thanks,
Jason
On Tue, Jul 30, 2019 at 03:14:30PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 30, 2019 at 12:55:17PM +0000, 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
>
On Tue, Jul 30, 2019 at 08:52:01AM +0300, Christoph Hellwig wrote:
> 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
+), 26 deletions(-)
I also don't really like how the API sets up some things in the struct
and some things via arguments, so:
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Jul 30, 2019 at 08:51:58AM +0300, Christoph Hellwig wrote:
> 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
ount of code compiled for non-x86 platforms, and also fixes compile
> failures with other architectures when helpers like pud_pfn are not
> implemented.
>
> Signed-off-by: Christoph Hellwig
> ---
> mm/hmm.c | 29 -
> 1 file changed, 16 insertions(+), 13
--
> mm/hmm.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Wed, Aug 07, 2019 at 06:57:24AM +, Koenig, Christian wrote:
> Am 06.08.19 um 22:03 schrieb Jason Gunthorpe:
> > On Tue, Aug 06, 2019 at 02:58:58PM -0400, Alex Deucher wrote:
> >> On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix
> >> wrote:
> >>> On
ver the place. Then the most
xa_loads would be eliminated, as I would expect the pgmap tends to be
mostly uniform for these use cases.
Is there some reason the pgmap ref can't be held across
faulting/sleeping? ie like below.
Anyhow, I looked over this pretty carefully and the change looks
functional
ig
> ---
> mm/hmm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
There sure are a lot of different ways to express this, but this one
looks OK to me, at least the switch from the PTRS_PER_PTE expression
in the x86 imlpementation to PMD_MASK looks equivalent
Reviewed-by:
On Tue, Aug 06, 2019 at 07:05:38PM +0300, Christoph Hellwig wrote:
>
> Hi Jérôme, Ben, Felix 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:
>
> 11 files changed, 94
= hmm_device_entry_from_pfn(range, pfn) |
> cpu_flags;
> hmm_vma_walk->last = end;
> @@ -850,14 +837,13 @@ static void hmm_pfns_clear(struct hmm_range *range,
> */
> int hmm_range_register(struct hmm_range *range, struct hmm_mirror *mirror)
> {
> - unsigned long mask = ((1UL << range->page_shift) - 1UL);
> struct hmm *hmm = mirror->hmm;
> unsigned long flags;
>
> range->valid = false;
> range->hmm = NULL;
>
> - if ((range->start & mask) || (range->end & mask))
> + if ((range->start & (PAGE_SIZE - 1)) || (range->end & (PAGE_SIZE - 1)))
> return -EINVAL;
PAGE_SIZE-1 == PAGE_MASK ? If yes I can fix it
Reviewed-by: Jason Gunthorpe
Jason
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Wed, Jul 31, 2019 at 01:25:06PM +, Kuehling, Felix wrote:
> On 2019-07-30 1:51 a.m., Christoph Hellwig wrote:
> > 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.
>
> I've seen code that uses
ort to avoid the arch restriction on hmm or
something? Also can't see why this was like this.
Reviewed-by: Jason Gunthorpe
Jason
drivers/gpu/drm/amd/amdgpu/Kconfig | 4 +++-
> drivers/gpu/drm/nouveau/Kconfig| 4 +++-
> mm/Kconfig | 14 ++
> 3 files changed, 12 insertions(+), 10 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
On Tue, Aug 06, 2019 at 07:05:46PM +0300, Christoph Hellwig wrote:
> 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(-)
Reviewed-by: Jason Gunthorpe
Jason
lock and unlock it.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/nouveau/nouveau_svm.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
changed, 8 insertions(+), 10 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Tue, Aug 06, 2019 at 02:58:58PM -0400, Alex Deucher wrote:
> On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix wrote:
> >
> > On 2019-08-06 13:44, Jason Gunthorpe wrote:
> > > On Tue, Aug 06, 2019 at 07:05:53PM +0300, Christoph Hellwig wrote:
> > >> The opti
On Mon, Jul 22, 2019 at 11:44:24AM +0200, Christoph Hellwig wrote:
> Currently nouveau_svm_fault expects nouveau_range_fault to never unlock
> mmap_sem, but the latter unlocks it for a random selection of error
> codes. Fix this up by always unlocking mmap_sem for non-zero return
> values in
gt; ---
> drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Agree
Reviewed-by: Jason Gunthorpe
Jason
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
gt; drivers/gpu/drm/nouveau/nouveau_svm.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
Code seems fine
Reviewed-by: Jason Gunthorpe
Jason
On Mon, Jul 22, 2019 at 11:44:20AM +0200, 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 and while at it also removes leftover legacy HMM APIs
> only used by nouveau.
>
> The first 4 patches are a
; 2 files changed, 43 insertions(+), 56 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
}
> > + if (!range->valid)
> > + return -EBUSY;
>
> Is it fine to remove up_read(>mm->mmap_sem) ?
It seems very subtle, but under the covers this calls
handle_mm_fault() with FAULT_FLAG_ALLOW_RETRY which will cause the
mmap sem to b
On Mon, Jul 22, 2019 at 06:11:04PM -0700, Ralph Campbell wrote:
>
> On 7/22/19 2:44 AM, 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 and while at it also removes leftover legacy HMM APIs
>
On Tue, Jul 23, 2019 at 07:23:35PM +0200, Christoph Hellwig wrote:
> 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
On Tue, Jul 23, 2019 at 06:30:48PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 23, 2019 at 03:18:28PM +0000, Jason Gunthorpe wrote:
> > Hum..
> >
> > The caller does this:
> >
> > again:
> > ret = nouveau_range_fault(&
On Tue, Jul 23, 2019 at 06:19:07PM +0200, Christoph Hellwig wrote:
> On Tue, Jul 23, 2019 at 02:54:45PM +0000, 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
> >
se the hmm->notifiers counter becomes unable to get to 0.
Below is the best idea I've had so far..
Michal, what do you think?
>From 53638cd1cb02e65e670c5d4edfd36d067bb48912 Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe
Date: Wed, 24 Jul 2019 12:15:40 -0300
Subject: [PATCH] mm/mmu_notifiers:
On Wed, Jul 24, 2019 at 05:33:05PM +0200, Christoph Hellwig wrote:
> 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
On Wed, Jul 24, 2019 at 07:58:58PM +0200, Michal Hocko wrote:
> On Wed 24-07-19 12:28:58, Jason Gunthorpe wrote:
> > On Wed, Jul 24, 2019 at 09:05:53AM +0200, Christoph Hellwig wrote:
> > > Looks good:
> > >
> > > Reviewed-by: Christoph Hellwig
> >
1 - 100 of 345 matches
Mail list logo
