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: J
On Thu, Jun 13, 2019 at 11:21:01PM +0200, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 08:40:46PM +0000, Jason Gunthorpe wrote:
> > > Perhaps we should pull those out and resend them through hmm.git?
> >
> > It could be done - but how bad is the conflict resolution
ke device would need a
chardev, with a stanadrd '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
___
; drivers/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
__
e doesn't seem worth worrying about.
Reviewed-by: Christoph Hellwig
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 y
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
Shared Virtual Memory (SVM).
Maybe it should be depends on STAGING not broken?
or maybe nouveau_svm doesn't actually need DEVICE_PRIVATE?
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Jason Gunthorpe
Ralph observes that hmm_range_register() can only be called by a driver
while a mirror is registered. Make this clear in the API by passing in the
mirror structure as a parameter.
This also simplifies understanding the lifetime model for struct hmm, as
the hmm pointer must
From: Jason Gunthorpe
So long as a struct hmm pointer exists, so should the struct mm it is
linked too. Hold the mmgrab() as soon as a hmm is created, and mmdrop() it
once the hmm refcount goes to zero.
Since mmdrop() (ie a 0 kref on struct mm) is now impossible with a !NULL
mm->hmm delete
From: Jason Gunthorpe
As coded this function can false-fail in various racy situations. Make it
reliable and simpler by running under the write side of the mmap_sem and
avoiding the false-failing compare/exchange pattern. Due to the mmap_sem
this no longer has to avoid racing with a 2nd parallel
-
> 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
___
dri-devel mailing list
dri-dev
d, 2 insertions(+), 1 deletion(-)
Reviewed-by: Jason Gunthorpe
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Jason Gunthorpe
If the trylock on the hmm->mirrors_sem fails the function will return
without decrementing the notifiers that were previously incremented. Since
the caller will not call invalidate_range_end() on EAGAIN this will result
in notifiers becoming permanently incremented
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, whi
re driver 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
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
Tested-by: Philip Yang
---
v2
- Fix missing & in lockdeps (Jason)
---
mm/hmm.c | 4 ++-
From: Jason Gunthorpe
This patch series arised out of discussions with Jerome when looking at the
ODP changes, particularly informed by use after free races we have already
found and fixed in the ODP code (thanks to syzkaller) working with mmu
notifiers, and the discussion with Ralph on how to
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 Glisse
Reviewed-by: John Hubbard
Acked-by: Souptick Joarder
Reviewed-by: Ralph Campbell
Acked
From: Jason Gunthorpe
Range functions like hmm_range_snapshot() and hmm_range_fault() call
find_vma, which requires hodling the mmget() and the mmap_sem for the mm.
Make this simpler for the callers by holding the mmget() inside the range
for the lifetime of the range. Other functions that
From: Jason Gunthorpe
No other register/unregister kernel API attempts to provide this kind of
protection as it is inherently racy, so just drop it.
Callers should provide their own protection, it appears nouveau already
does, but just in case drop a debugging POISON.
Signed-off-by: Jason
m/hmm.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...
Revi
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
>
On Wed, Jun 12, 2019 at 09:49:12PM +, Yang, Philip wrote:
> Rebase to https://github.com/jgunthorpe/linux.git hmm branch, need some
> changes because of interface hmm_range_register change. Then run a quick
> amdgpu_test. Test is finished, result is ok.
Great! Thanks
I'll add your Tested-by
From: Jason Gunthorpe
mmu_notifier_unregister_no_release() is not a fence and the mmu_notifier
system will continue to reference hmm->mn until the srcu grace period
expires.
Resulting in use after free races like this:
CPU0 C
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Jason Gunthorpe
hmm_release() is called exactly once per hmm. ops->release() cannot
accidentally trigger any action that would recurse back onto
hmm->mirrors_sem.
This fixes a use after-free race of the form:
CPU0
>
> I found this while testing Jason Gunthorpe's hmm tree but this is
> independant of those changes. I guess it could go through
> David Airlie's tree for nouveau or Jason's tree.
This seems like a bad enough bug to send it into -rc?
It probably should go
On Sat, Jun 15, 2019 at 07:21:06AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 09:44:49PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > hmm_release() is called exactly once per hmm. ops->release() cannot
> > accidentally trigger any
On Sat, Jun 15, 2019 at 07:18:26AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 09:44:48PM -0300, Jason Gunthorpe wrote:
> > range->hmm = hmm;
> > kref_get(&hmm->kref);
> > - list_add_rcu(&range->list, &hmm->ranges)
m_free?
It was late when I wrote this fixup, the comment is faulty, and there
is no reason to delay this until the SRCU cleanup at this point in the
series.
The ops all get their struct hmm from container_of, the only thing
that refers to mm->hmm is hmm_get_or_create().
I'll revise it tom
On Sat, Jun 15, 2019 at 06:59:06AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 09:44:40PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > Ralph observes that hmm_range_register() can only be called by a driver
> > while a mirror is registe
*/
>
> The comment confuses me. How does the page_table_lock relate to
> possibly running notifiers, as I can't find that we take
> page_table_lock? Or is it just about the fact that we only clear
> mm->hmm in the free callback, and not in hmm_free?
Revised with:
From
On Sat, Jun 15, 2019 at 07:14:35AM -0700, Christoph Hellwig wrote:
> > mutex_lock(&hmm->lock);
> > - list_for_each_entry(range, &hmm->ranges, list)
> > - range->valid = false;
> > - wake_up_all(&hmm->wq);
> > + /*
> > +* Since hmm_range_register() holds the mmget() lock hmm_
e;
> > + memset(&range->hmm, POISON_INUSE, sizeof(range->hmm));
>
> Formatting seems to be messed up. But again I don't see the value
> in the poisoning, just let normal linked list debugging do its work.
> The other cleanups looks fine to me.
tabs vs spa
On Sat, Jun 15, 2019 at 07:16:12AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 09:44:46PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > No other register/unregister kernel API attempts to provide this kind of
> > protection as it is in
On Tue, Jun 18, 2019 at 06:27:22AM -0700, Christoph Hellwig wrote:
> On Tue, Jun 18, 2019 at 10:13:24AM -0300, Jason Gunthorpe wrote:
> > > I don't even think we even need to bother with the POISON, normal list
> > > debugging will already catch a double unregistration an
nchronization
* can only be safe if the only activity that can happen
* to the list entry is list_del_init(). Eg. it cannot be used
* if another CPU could re-list_add() it.
*/
Agree it doesn't seem obvious why this is relevant when checking the
list head..
Maybe the comment is a bit misleadi
r exist so long as objects exist, or it can
exist until the chardev is closed - but never longer than the
chardev's lifetime.
Maybe we should be considering providing a mmu notifier & interval
tree & lock abstraction since ODP & AMD are very similar here..
Jason
__
without page backing.
Gah, this addr gets fed into io_remap_pfn_range/remap_pfn_range too..
Potnuri, you should fix this..
You probably need to use dma_mmap_from_dev_coherent() in the mmap ?
Jason
ile a random pr_warn probably will
not.
I do agree the backtrace is not useful here, but we don't have a
warn-no-backtrace version..
IMHO, kernel/driver bugs should always be reported by WARN &
friends. We never expect to see the print, so why do we care how big
it is?
Also note that WARN integrates an unlikely() into it so the codegen is
automatically a bit more optimal that the if & pr_warn combination.
Jason
On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe wrote:
> > On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> > > On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > > >
On Wed, Jun 19, 2019 at 10:18:43PM +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 10:13 PM Jason Gunthorpe wrote:
> > On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe wrote:
> > > > On T
t needs to go to DRM, AMD
and RDMA git trees)..
Instead I will merge v5.2-rc5 to the tree before applying this series.
I've understood this to be Linus's prefered workflow.
So, please send the next iteration of this against either
plainv5.2-rc5 or v5.2-rc5 merged with
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 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:
> >>>
> ...
> >>
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 Glisse
Reviewed-by: John Hubbard
Acked-by: Souptick Joarder
Reviewed-by: Ralph Campbell
Reviewed
From: Jason Gunthorpe
No other register/unregister kernel API attempts to provide this kind of
protection as it is inherently racy, so just drop it.
Callers should provide their own protection, and it appears nouveau
already does.
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jérôme Glisse
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
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
---
v2
- Fix missing & in lock
From: Jason Gunthorpe
hmm_release() is called exactly once per hmm. ops->release() cannot
accidentally trigger any action that would recurse back onto
hmm->mirrors_sem.
This fixes a use after-free race of the form:
CPU0
From: Jason Gunthorpe
If the trylock on the hmm->mirrors_sem fails the function will return
without decrementing the notifiers that were previously incremented. Since
the caller will not call invalidate_range_end() on EAGAIN this will result
in notifiers becoming permanently incremented
From: Jason Gunthorpe
The wait_event_timeout macro already tests the condition as its first
action, so there is no reason to open code another version of this, all
that does is skip the might_sleep() debugging in common cases, which is
not helpful.
Further, based on prior patches, we can now
From: Jason Gunthorpe
As coded this function can false-fail in various racy situations. Make it
reliable and simpler by running under the write side of the mmap_sem and
avoiding the false-failing compare/exchange pattern. Due to the mmap_sem
this no longer has to avoid racing with a 2nd parallel
From: Jason Gunthorpe
mmu_notifier_unregister_no_release() is not a fence and the mmu_notifier
system will continue to reference hmm->mn until the srcu grace period
expires.
Resulting in use after free races like this:
CPU0 C
From: Jason Gunthorpe
Ralph observes that hmm_range_register() can only be called by a driver
while a mirror is registered. Make this clear in the API by passing in the
mirror structure as a parameter.
This also simplifies understanding the lifetime model for struct hmm, as
the hmm pointer must
From: Jason Gunthorpe
Range functions like hmm_range_snapshot() and hmm_range_fault() call
find_vma, which requires hodling the mmget() and the mmap_sem for the mm.
Make this simpler for the callers by holding the mmget() inside the range
for the lifetime of the range. Other functions that
From: Jason Gunthorpe
So long as a struct hmm pointer exists, so should the struct mm it is
linked too. Hold the mmgrab() as soon as a hmm is created, and mmdrop() it
once the hmm refcount goes to zero.
Since mmdrop() (ie a 0 kref on struct mm) is now impossible with a !NULL
mm->hmm delete
From: Jason Gunthorpe
This patch series arised out of discussions with Jerome when looking at the
ODP changes, particularly informed by use after free races we have already
found and fixed in the ODP code (thanks to syzkaller) working with mmu
notifiers, and the discussion with Ralph on how to
; create a conflict with another tree cleaning things up around the
> is_device_private defintion, but otherwise I'd be glad to just remove
> it.
>
> Jason, as this goes through your tree, do you mind the additional
> conflict?
Which tree and what does the resolution look lik
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 files c
.h | 3 ---
> mm/hmm.c| 14 --
> 2 files changed, 17 deletions(-)
Reviewed-by: Jason Gunthorpe
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
t_held(&hmm->ranges_lock);
> > +
>
> Why not acquire the lock here and release at the end instead
> of asserting the lock is held?
> It looks like everywhere notifiers_decrement() is called does
> that.
Yes, this is just some left over mistake, thanks
From aa371c720a9e3c632d
le | 2 +-
> mm/hmm.c| 2 --
> 6 files changed, 8 insertions(+), 33 deletions(-)
Makes more sense to me too
Reviewed-by: Jason Gunthorpe
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop
--
> 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_f
On Mon, Jun 24, 2019 at 06:00:58PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> This patch series arised out of discussions with Jerome when looking at the
> ODP changes, particularly informed by use after free races we have already
> found and fixed in the ODP
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, 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:
s/dax/device.c | 43 ---
> 2 files changed, 47 deletions(-)
DanW: I think this series has reached enough review, did you want
to ack/test any further?
This needs to land in hmm.git soon to make the merge window.
Thanks,
Jason
__
are going to have to merge hmm.git into the amdgpu tree and
push the resolution forward, as it looks kind of complicated to shift
onto Linus or DRM.
Probably amdgpu needs to gain a few patches making the hmm_mirror
visible to amdgpu_ttm.c and then the merge resolution will be sim
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..
ch sense, I'd like to apply this in hmm.git, is there
any objection?
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
I understand Andrew will handle these
post-linux-next
- The conflict with AMD GPU in -next, I am waiting to hear from AMD
Otherwise I think we are done with hmm.git for this
cycle.
Unfortunately this is still not enough to progress rdma's ODP, so we
will need to do this again next cy
On Wed, Jul 03, 2019 at 12:49:12AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 02, 2019 at 07:53:23PM +0000, Jason Gunthorpe wrote:
> > > I'm sending this out now since we are updating many of the HMM APIs
> > > and I think it will be useful.
> >
> > This
On Wed, Jul 03, 2019 at 02:27:22AM +, Kuehling, Felix wrote:
> On 2019-07-02 6:59 p.m., Jason Gunthorpe wrote:
> > On Wed, Jul 03, 2019 at 12:49:12AM +0200, Christoph Hellwig wrote:
> >> On Tue, Jul 02, 2019 at 07:53:23PM +, Jason Gunthorpe wrote:
> >>>>
essible from bo.
>
> Signed-off-by: Philip Yang
> Reviewed-by: Felix Kuehling
> Signed-off-by: Felix Kuehling
> CC: Stephen Rothwell
> CC: Jason Gunthorpe
> CC: Dave Airlie
> CC: Alex Deucher
> ---
> drivers/gpu/drm/Kconfig | 1 -
>
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 th
On Wed, Jul 03, 2019 at 05:09:16PM -0400, Alex Deucher wrote:
> On Wed, Jul 3, 2019 at 5:03 PM Kuehling, Felix wrote:
> >
> > On 2019-07-03 10:10 a.m., Jason Gunthorpe wrote:
> > > On Wed, Jul 03, 2019 at 01:55:08AM +, Kuehling, Felix wrote:
> > >> From: Ph
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 a consistent pattern so we can then
easily hoist the seqcount lock scheme into some common mmu notifier
code, as discussed.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ng
this already obsolete API in their latest driver :(
So, we now need to get both drivers to move to the modern API.
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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 :(
> >
>
now what you'd like please
Reviewed-by: Jason Gunthorpe
Thanks,
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
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
le) and then your tree (and consequently the drm
> > tree) would also not be mergeable.
> >
>
> I'm fine with merging the hmm tree if Jason has a stable non-rebasing
> base. I'd rather merge into drm tree and then have amd backmerge if it
> we are doing it.
Yes
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.
>
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 l
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 Mon, Jul 08, 2019 at 09:30:20AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 3 Jul 2019 17:09:16 -0400 Alex Deucher wrote:
> >
> > On Wed, Jul 3, 2019 at 5:03 PM Kuehling, Felix
> > wrote:
> > >
> > > On 2019-07-03 10:10 a.m., Jason Gunth
it.
The tag for-linus-hmm-merged with my merge resolution to your tree is
also available to pull.
Thanks,
Jason
diff --cc mm/hmm.c
index d48b9283725a90,f702a3895d05d8..e1eedef129cf5c
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@@ -42,16 -54,11 +42,16 @@@ static const struct mmu_notifier_ops hm
On Tue, Jul 09, 2019 at 04:30:38PM +0200, Christoph Hellwig wrote:
> 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
->fn(pte, NULL, addr, pra->data);
> + return pra->fn(pte, addr, pra->data);
> }
I looked through this and it looks OK to me, thanks
Jason
next, similar for drm-fixes.
The DRM part seems logical - it is how the AMD GPU and nouveau git
trees trees work that I don't know. I heard that neither could take in
a stable topic branch?
Jason
> does ;/ ]
>
> On Mon, Jul 15, 2019 at 5:29 AM Jason Gunthorpe wrote:
> >
> > The 'hmm' tree is something I ran to try and help workflow issues like
> > this, as it could be merged to DRM as a topic branch - maybe consider
> > this flow in future?
> >
something uncontroversial that really should go into the DRM
world as a topic so it doesn't interfere with ongoing nouveau dev. But
I want to keep the hmm.c/.h bits in the hmm.git to avoid conflicts.
So, I'll put it on a topic and send you two a note next week to decide
if you want to
On Tue, Jul 16, 2019 at 12:42:07PM +0200, Andrey Konovalov wrote:
> On Mon, Jul 15, 2019 at 8:05 PM Jason Gunthorpe wrote:
> >
> > On Mon, Jul 15, 2019 at 06:01:29PM +0200, Andrey Konovalov wrote:
> > > On Mon, Jun 24, 2019 at 7:40 PM Catalin Marinas
> > > wrot
eans something like
'why are you using this? you probably should not'
Often because the __ version has no locking or some other dangerous
configuration like that.
Jason
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(&svmm->
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
gt; drivers/gpu/drm/nouveau/nouveau_svm.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
Code seems fine
Reviewed-by: Jason Gunthorpe
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailm
IN;
> > - }
> > + if (!range->valid)
> > + return -EBUSY;
>
> Is it fine to remove up_read(&hmm->mm->mmap_sem) ?
It seems very subtle, but under the covers this calls
handle_mm_fault() with FAULT_FLAG_ALLOW_RETRY
901 - 1000 of 3408 matches
Mail list logo
