Re: [PATCH V2] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

On Wed, Apr 11, 2018 at 01:03:59PM +0100, Robin Murphy wrote: > On 10/04/18 21:59, Sinan Kaya wrote: >> Code is expecing to observe the same number of buffers returned from >> dma_map_sg() function compared to sg_alloc_table_from_pages(). This >> doesn't hold true universally especially for

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote: > > Yes there's a bit a layering violation insofar that drivers really > > shouldn't each have their own copy of "how do I convert a piece of dma > > memory into dma-buf", but that doesn't render the interface a bad idea. > >

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote: > > > What we need is an sg_alloc_table_from_resources(dev, resources, > > > num_resources) which does the handling common to all drivers. > > A structure that contains > > > > {page,offset,len} + {dma_addr+dma_len} > > > > is not

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Tue, Apr 03, 2018 at 08:08:32PM +0200, Daniel Vetter wrote: > I did not mean you should dma_map_sg/page. I just meant that using > dma_map_resource to fill only the dma address part of the sg table seems > perfectly sufficient. But that is not how the interface work, especially facing

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote: > We've broken that assumption in i915 years ago. Not struct page backed > gpu memory is very real. > > Of course we'll never feed such a strange sg table to a driver which > doesn't understand it, but allowing sg_page == NULL works

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote: > > At the very lowest level they will need to be handled differently for > > many architectures, the questions is at what point we'll do the > > branching out. > > Having at least struct page also in that list with (dma_addr_t,

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 08:23:15AM +0200, Daniel Vetter wrote: > For more fun: > > https://www.spinics.net/lists/dri-devel/msg173630.html > > Yeah, sometimes we want to disable the iommu because the on-gpu > pagetables are faster ... I am not on this list, but remote NAK from here. This needs

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote: > Can we please not nack everything right away? Doesn't really motivate > me to show you all the various things we're doing in gpu to make the > dma layer work for us. That kind of noodling around in lower levels to > get them to do

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote: > > It has a non-coherent transaction mode (which the chipset can opt to > > not implement and still flush), to make sure the AGP horror show > > doesn't happen again and GPU folks are happy with PCIe. That's at > > least my

noveau vs arm dma ops

[discussion about this patch, which should have been cced to the iommu and linux-arm-kernel lists, but wasn't: https://www.spinics.net/lists/dri-devel/msg173630.html] On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry Reding wrote: > > API from the iommu/dma-mapping code. Drivers have no

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 09:56:43AM +0200, Thierry Reding wrote: > And to add to the confusion, none of this seems to be an issue on 64-bit > ARM where the generic DMA/IOMMU code from drivers/iommu/dma-iommu.c is > used. In the long term I want everyone to use that code. Help welcome!

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: > > Coordinating the backport of a trivial helper in the arm tree is not > > the end of the world. Really, this cowboy attitude is a good reason > > why graphics folks have such a bad rep. You keep poking into random > > kernel

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote: > dma_map_resource() is the right API (thought its current implementation > is fill with x86 assumptions). So i would argue that arch can decide to > implement it or simply return dma error address which trigger fallback > path into

Re: [PATCH 1/8] lib/scatterlist: add sg_set_dma_addr() helper

On Sun, Mar 25, 2018 at 12:59:53PM +0200, Christian König wrote: > Use this function to set an sg entry to point to device resources mapped > using dma_map_resource(). The page pointer is set to NULL and only the DMA > address, length and offset values are valid. NAK. Please provide a higher

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote: > From: "wda...@nvidia.com" > > Add an interface to find the first device which is upstream of both > devices. Please work with Logan and base this on top of the outstanding peer to peer patchset.

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote: > > get_required_mask() is supposed to tell you if you are safe. However > > we are missing lots of implementations of it for iommus so you might get > > some false negatives, improvements welcome. It's been on my list of > > things

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 11:54:43PM +0100, Russell King - ARM Linux wrote: > > if the memory was previously dirty (iow, CPU has written), you need to > flush the dirty cache lines _before_ the GPU writes happen, but you > don't know whether the CPU has speculatively prefetched, so you need > to

Re: [Linaro-mm-sig] noveau vs arm dma ops

On Thu, Apr 26, 2018 at 11:20:44AM +0200, Daniel Vetter wrote: > The above is already what we're implementing in i915, at least > conceptually (it all boils down to clflush instructions because those > both invalidate and flush). The clwb instruction that just writes back dirty cache lines might

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

Hmm, I wonder if we are not actually using swiotlb in the end, can you check if your dmesg contains this line or not? PCI-DMA: Using software bounce buffering for IO (SWIOTLB) If not I guess we found a bug in swiotlb exit vs is_swiotlb_buffer, and you can try this patch: diff --git

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

On Thu, Jan 10, 2019 at 06:52:26PM +0100, Sibren Vasse wrote: > On Thu, 10 Jan 2019 at 15:48, Christoph Hellwig wrote: > > > > On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote: > > >> From the trace it looks like we git the case where swiotlb tries &g

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

> +#include This header is not for usage in device drivers, but purely for dma-mapping implementations! > +static inline bool drm_device_can_wc_memory(struct drm_device *ddev) > { > + if (IS_ENABLED(CONFIG_PPC)) > + return IS_ENABLED(CONFIG_NOT_COHERENT_CACHE); > + else if

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Mon, Jan 21, 2019 at 04:33:27PM +0100, Ard Biesheuvel wrote: > On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig wrote: > > > > > +#include > > > > This header is not for usage in device drivers, but purely for > > dma-mapping implementations! > > >

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Mon, Jan 21, 2019 at 05:30:00PM +0100, Ard Biesheuvel wrote: > > Until that happens we should just change the driver ifdefs to default > > the hacks to off and only enable them on setups where we 100% > > positively know that they actually work. And document that fact > > in big fat comments.

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Mon, Jan 21, 2019 at 05:14:37PM +0100, Ard Biesheuvel wrote: > > I'll add big fat comments. But the fact that nothing is exported > > there should be a fairly big hint. > > > > I don't follow. How do other header files 'export' things in a way > that this header doesn't? Well, I'll add

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Tue, Jan 22, 2019 at 10:07:07PM +0100, Ard Biesheuvel wrote: > Yes, so much was clear. And the reason this breaks on some arm64 > systems is because > a) non-snooped PCIe TLP attributes may be ignored, and > b) non-x86 CPUs do not snoop the caches when accessing uncached mappings. > > I don't

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

I think we just want a driver-local check for those combinations where we know this hack actually works, which really just seems to be x86-64 with PAT. Something like the patch below, but maybe with even more strong warnings to not do something like this elsewhere: diff --git

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

On Thu, Jan 10, 2019 at 10:59:02AM +0100, Michel Dänzer wrote: > > Hi Christoph, > > > https://bugs.freedesktop.org/109234 (please ignore comments #6-#9) was > bisected to your commit 55897af63091 "dma-direct: merge swiotlb_dma_ops > into the dma_direct code". Any ideas? From the trace it

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote: >> From the trace it looks like we git the case where swiotlb tries >> to copy back data from a bounce buffer, but hits a dangling or NULL >> pointer. So a couple questions for the submitter: >> >> - does the system have more

Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86

On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote: > But my concern is that it seems likely that non-cache coherent > implementations are relying on this hack as well. There must be a > reason that this hack is only disabled for PowerPC platforms if they > are cache coherent, for

Re: [PATCH v15 00/17] arm64: untag user pointers passed to the kernel

On Tue, May 28, 2019 at 04:14:45PM +0200, Andrey Konovalov wrote: > Thanks for a lot of valuable input! I've read through all the replies > and got somewhat lost. What are the changes I need to do to this > series? > > 1. Should I move untagging for memory syscalls back to the generic > code so

Re: [PATCH v16 01/16] uaccess: add untagged_addr definition for other arches

On Mon, Jun 03, 2019 at 11:24:35AM -0600, Khalid Aziz wrote: > On 6/3/19 11:06 AM, Andrey Konovalov wrote: > > On Mon, Jun 3, 2019 at 7:04 PM Khalid Aziz wrote: > >> Andrey, > >> > >> This patch has now become part of the other patch series Chris Hellwig > >> has sent out - > >>

Re: [PATCH v3 hmm 12/12] mm/hmm: Fix error flows in hmm_invalidate_range_start

elease(struct mmu_notifier *mn, struct > mm_struct *mm) > hmm_put(hmm); > } > > +static void notifiers_decrement(struct hmm *hmm) > +{ > + lockdep_assert_held(>ranges_lock); > + > + hmm->notifiers--; > + if (!hmm->notifiers) {

Re: [PATCH v3 hmm 05/12] mm/hmm: Remove duplicate condition test before wait_event_timeout

Looks good, Reviewed-by: Christoph Hellwig ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 hmm 04/12] mm/hmm: Simplify hmm_get_or_create and make it reliable

> + spin_lock(>page_table_lock); > + if (mm->hmm) { > + if (kref_get_unless_zero(>hmm->kref)) { > + spin_unlock(>page_table_lock); > + return mm->hmm; > + } > + } > + spin_unlock(>page_table_lock); This could become:

Re: [PATCH v3 hmm 06/12] mm/hmm: Hold on to the mmget for the lifetime of the range

evented as long as a range exists. > + */ > + WARN_ON(!list_empty(>ranges)); > mutex_unlock(>lock); This can just use list_empty_careful and avoid the lock entirely. Otherwise looks good: Reviewed-by: Christoph Hellwig ___ amd-gfx

Re: [PATCH v3 hmm 03/12] mm/hmm: Hold a mmgrab from hmm to mm

Looks good, Reviewed-by: Christoph Hellwig ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 hmm 02/12] mm/hmm: Use hmm_mirror not mm as an argument for hmm_range_register

> > This also simplifies understanding the lifetime model for struct hmm, as > the hmm pointer must be valid as part of a registered mirror so all we > need in hmm_register_range() is a simple kref_get. Looks good, at least an an intermediate step: Reviewed-by: Christoph Hellw

Re: [PATCH v3 hmm 11/12] mm/hmm: Remove confusing comment and logic from hmm_release

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 action that would recurse back onto > hmm->mirrors_sem. In linux-next amdgpu actually calls

Re: [PATCH v3 hmm 01/12] mm/hmm: fix use after free with struct hmm in the mmu notifiers

Looks good, Reviewed-by: Christoph Hellwig ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 hmm 07/12] mm/hmm: Use lockdep instead of comments

Looks good, Reviewed-by: Christoph Hellwig ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v3 hmm 10/12] mm/hmm: Do not use list*_rcu() for hmm->ranges

e have to wait for them for > @@ -934,7 +934,7 @@ void hmm_range_unregister(struct hmm_range *range) > struct hmm *hmm = range->hmm; > > mutex_lock(>lock); > - list_del_rcu(>list); > + list_del(>list); > mutex_unlock(>lock); Looks fi

Re: [PATCH v3 hmm 09/12] mm/hmm: Poison hmm_range during unregister

> - /* Sanity check this really should not happen. */ > - if (hmm == NULL || range->end <= range->start) > - return; > - > mutex_lock(>lock); > list_del_rcu(>list); > mutex_unlock(>lock); > > /* Drop reference taken by hmm_range_register() */ > -

Re: [PATCH v3 hmm 08/12] mm/hmm: Remove racy protection against double-unregistration

it appears nouveau already > does, but just in case drop a debugging POISON. I don't even think we even need to bother with the POISON, normal list debugging will already catch a double unregistration anyway. Otherwise looks fine: Reviewed-by: Christoph Hellwig __

Re: [PATCH v3 hmm 11/12] mm/hmm: Remove confusing comment and logic from hmm_release

On Mon, Jun 17, 2019 at 09:45:09PM -0300, Jason Gunthorpe wrote: > Am I looking at the wrong thing? Looks like it calls it through a work > queue should should be OK.. Yes, it calls it through a work queue. I guess that is fine because it needs to take the lock again. > Though very strange that

Re: [PATCH v3 hmm 08/12] mm/hmm: Remove racy protection against double-unregistration

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 anyway. > > mirror->hmm isn't a list so list debugging won't help. > > My concern when I wrote this

Re: [PATCH v4 hmm 04/12] mm/hmm: Simplify hmm_get_or_create and make it reliable

Looks good, Reviewed-by: Christoph Hellwig ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v4 hmm 11/12] mm/hmm: Remove confusing comment and logic from hmm_release

Looks good, Reviewed-by: Christoph Hellwig ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 hmm 02/11] mm/hmm: Use hmm_mirror not mm as an argument for hmm_range_register

On Tue, Jun 11, 2019 at 04:44:31PM -0300, Jason Gunthorpe wrote: > On Sat, Jun 08, 2019 at 01:54:25AM -0700, Christoph Hellwig wrote: > > FYI, I very much disagree with the direction this is moving. > > > > struct hmm_mirror literally is a trivial duplication of the &g

Re: [PATCH v2 hmm 02/11] mm/hmm: Use hmm_mirror not mm as an argument for hmm_range_register

On Wed, Jun 12, 2019 at 08:41:25AM -0300, Jason Gunthorpe wrote: > > I like the idea. A few nitpicks: Can we avoid having to store the > > mm in struct mmu_notifier? I think we could just easily pass it as a > > parameter to the helpers. > > Yes, but I think any driver that needs to use this API

Re: [PATCH v3 hmm 06/12] mm/hmm: Hold on to the mmget for the lifetime of the range

On Wed, Jun 19, 2019 at 08:34:52AM -0300, Jason Gunthorpe wrote: > /** > * list_empty_careful - tests whether a list is empty and not being modified > * @head: the list to test > * > * Description: > * tests whether a list is empty _and_ checks that no other CPU might be > * in the process

Re: [PATCH v3 hmm 02/12] mm/hmm: Use hmm_mirror not mm as an argument for hmm_range_register

On Tue, Jun 18, 2019 at 10:05:44AM -0300, Jason Gunthorpe wrote: > I'm thinking to tackle that as part of the mmu notififer invlock > idea.. Once the range looses the lock then we don't really need to > register it at all. Ok. ___ amd-gfx mailing list

Re: [PATCH v3 hmm 11/12] mm/hmm: Remove confusing comment and logic from hmm_release

On Wed, Jun 19, 2019 at 12:53:55AM +, Kuehling, Felix wrote: > This code is derived from our old MMU notifier code. Before HMM we used > to register a single MMU notifier per mm_struct and look up virtual > address ranges that had been registered for mirroring via driver API > calls. The

Re: [PATCH v3 hmm 11/12] mm/hmm: Remove confusing comment and logic from hmm_release

On Wed, Jun 19, 2019 at 08:56:32AM -0300, Jason Gunthorpe wrote: > This looks a lot like the ODP code (amdgpu_mn_node == ib_umem_odp) > > The interval tree is to quickly find the driver object(s) that have > the virtual pages during invalidation: > > static int

Re: [PATCH v3 hmm 08/12] mm/hmm: Remove racy protection against double-unregistration

On Tue, Jun 18, 2019 at 03:57:57PM -0300, Jason Gunthorpe wrote: > With the previous loose coupling of the mirror and the range some code > might rance to try to create a range without a mirror, which will now > reliably crash with the poison. > > It isn't so much the double unregister that

Re: [PATCH v3 hmm 06/12] mm/hmm: Hold on to the mmget for the lifetime of the range

> mutex_lock(>lock); > - list_del(>list); > + list_del_init(>list); > mutex_unlock(>lock); I don't see the point why this is a list_del_init - that just reinitializeѕ range->list, but doesn't change anything for the list head it was removed from. (and if the list_del_init was

Re: [PATCH v2 hmm 02/11] mm/hmm: Use hmm_mirror not mm as an argument for hmm_range_register

FYI, I very much disagree with the direction this is moving. struct hmm_mirror literally is a trivial duplication of the mmu_notifiers. All these drivers should just use the mmu_notifiers directly for the mirroring part instead of building a thing wrapper that adds nothing but helping to manage

Re: [PATCH v2 hmm 01/11] mm/hmm: fix use after free with struct hmm in the mmu notifiers

I still think sruct hmm should die. We already have a structure used for additional information for drivers having crazly tight integration into the VM, and it is called struct mmu_notifier_mm. We really need to reuse that intead of duplicating it badly.

Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote: > HMM defines its own struct hmm_update which is passed to the > sync_cpu_device_pagetables() callback function. This is > sufficient when the only action is to invalidate. However, > a device may want to know the reason for the

Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

On Tue, Jul 02, 2019 at 10:59:16PM +, Jason Gunthorpe wrote: > > As this creates a somewhat hairy conflict for amdgpu, wouldn't it be > > a better idea to wait a bit and apply it first thing for next merge > > window? > > My thinking is that AMD GPU already has a monster conflict from this: >

Re: [RFC] mm/hmm: pass mmu_notifier_range to sync_cpu_device_pagetables

On Tue, Jul 02, 2019 at 07:53:23PM +, 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 make so much sense, I'd like to apply this in hmm.git, is there > any objection? As this creates a somewhat hairy

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Fri, Aug 16, 2019 at 12:30:41PM +, Jason Gunthorpe wrote: > > For instance, a system may have multiple DEVICE_PRIVATE map's owned by > the same driver - but multiple physical devices using that driver. > > Each physical device's driver should only ever get DEVICE_PRIVATE > pages for it's

[PATCH 3/4] drm/radeon: simplify and cleanup setting the dma mask

-by: Christoph Hellwig --- drivers/gpu/drm/radeon/radeon_device.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index b8cc05826667..88eb7cb522bb 100644 --- a/drivers/gpu/drm/radeon

[PATCH 4/4] drm/amdgpu: simplify and cleanup setting the dma mask

-by: Christoph Hellwig --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 - drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 21 ++--- drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 15 +++ drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 20 +++- drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c

Re: [PATCH 1/4] drm/radeon: handle PCIe root ports with addressing limitations

On Thu, Aug 15, 2019 at 08:34:10AM +, Koenig, Christian wrote: > Looks sane to me. Reviewed-by: Christian König . > > Should we merge this through our normal amdgpu/radeon branches or do you > want to send this upstream somehow else? This is intended for your trees.

[PATCH 1/4] drm/radeon: handle PCIe root ports with addressing limitations

instead to also take those into account. Reported-by: Atish Patra Signed-off-by: Christoph Hellwig --- drivers/gpu/drm/radeon/radeon.h| 1 - drivers/gpu/drm/radeon/radeon_device.c | 12 +--- drivers/gpu/drm/radeon/radeon_ttm.c| 2 +- 3 files changed, 6 insertions(+), 9

[PATCH 2/4] drm/amdgpu: handle PCIe root ports with addressing limitations

instead to also take those into account. Signed-off-by: Christoph Hellwig --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index e51b48ac48eb

fix radeon and amdgpu for addressing limited root ports

Hi AMD graphics maintainers, this series fixes a problem in the radeon driver for systems where the PCIe root port only supports limited (32-bit) addressing as reported by Atish. I then also fixed the same issue in amdgpu as the code was copy and pasted there, and cleaned up the dma mask setting

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

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), Both current hmm drivers convert the hmm pfn back to a page and eventually call dma_map_page on it. As do the ODP patches

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Fri, Aug 16, 2019 at 12:43:07AM +, 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 > > nouveau_dmem_page() to check that page page->pgmap == the > > expected pgmap. > > I was also wondering

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

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 case when the pgmap overlaps normal dram, i.e. shares > the same 'struct

Re: [PATCH] nouveau/hmm: map pages after migration

On Thu, Aug 08, 2019 at 02:29:34PM -0700, Ralph Campbell wrote: >>> { >>> struct nouveau_fence *fence; >>> unsigned long addr = args->start, nr_dma = 0, i; >>> for (i = 0; addr < args->end; i++) { >>> args->dst[i] = nouveau_dmem_migrate_copy_one(drm, args->vma,

Re: [PATCH 2/2] mm/hmm: hmm_range_fault() infinite loop

WRITE before calling > handle_mm_fault(). > > Signed-off-by: Ralph Campbell Looks good, Reviewed-by: Christoph Hellwig ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/2] mm/hmm: hmm_range_fault() NULL pointer bug

ned > within the vma range. Should we convert to walk_vma_range instead? Or keep walk_page_range but drop searching the vma ourselves? Except for that the patch looks good to me: Reviewed-by: Christoph Hellwig ___ amd-gfx mailing list amd-gfx@lists.

Re: [PATCH 2/4] mm/hmm: allow snapshot of the special zero page

MAing a zero page. > > Signed-off-by: Ralph Campbell > Cc: "Jérôme Glisse" > Cc: Jason Gunthorpe > Cc: Christoph Hellwig > --- > mm/hmm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/hmm.c b/mm/hmm.c > index 06041d4399ff

Re: [PATCH 1/4] mm/hmm: make full use of walk_page_range()

> +static int hmm_pfns_fill(unsigned long addr, > + unsigned long end, > + struct hmm_range *range, > + enum hmm_pfn_value_e value) Nit: can we use the space a little more efficient, e.g.: static int hmm_pfns_fill(unsigned long addr,

[PATCH 01/13] amdgpu: remove -EAGAIN handling for hmm_range_fault

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

[PATCH 10/13] mm: only define hmm_vma_walk_pud if needed

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

[PATCH 11/13] mm: cleanup the hmm_vma_handle_pmd stub

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

[PATCH 02/13] amdgpu: don't initialize range->list in amdgpu_hmm_init_range

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

[PATCH 08/13] mm: remove the mask variable in hmm_vma_walk_hugetlb_entry

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

[PATCH 04/13] mm: remove the pgmap field from struct hmm_vma_walk

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

[PATCH 13/13] mm: allow HMM_MIRROR on all architectures with MMU

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..b18782be969c

[PATCH 06/13] mm: remove superflous arguments from hmm_range_register

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

[PATCH 07/13] mm: remove the page_shift member from struct hmm_range

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

[PATCH 05/13] mm: remove the unused vma argument to hmm_range_dma_unmap

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

[PATCH 12/13] mm: cleanup the hmm_vma_walk_hugetlb_entry stub

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 b/mm

hmm_range_fault related fixes and legacy API removal v3

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:

[PATCH 09/13] mm: don't abuse pte_index() in hmm_vma_handle_pmd

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

[PATCH 03/13] nouveau: pass struct nouveau_svmm to nouveau_range_fault

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

Re: [PATCH 07/13] mm: remove the page_shift member from struct hmm_range

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

Re: [PATCH 03/13] nouveau: pass struct nouveau_svmm to nouveau_range_fault

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_fau

Re: [PATCH 03/13] nouveau: pass struct nouveau_svmm to nouveau_range_fault

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.

Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations

On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote: > readq/writeq are not supported on all architectures NAK. You must not use atomic_* on __iomem (MMIO) memory. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org

Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations

On Wed, Aug 07, 2019 at 08:53:25AM +, Koenig, Christian wrote: > Am 07.08.19 um 09:08 schrieb Christoph Hellwig: > > On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote: > >> readq/writeq are not supported on all architectures > > NAK. You must not use atomic_*

Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations

On Wed, Aug 07, 2019 at 10:55:01AM +, Koenig, Christian wrote: > >> Essentially writeq/readq doesn't seems to be available on all > >> architectures either. > > writeq/readq are provided whenever the CPU actually supports 64-bit > > atomic loads and stores. > > Is there a config option which

Re: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations

On Wed, Aug 07, 2019 at 01:00:48PM +, Koenig, Christian wrote: > Am 07.08.19 um 14:59 schrieb Mark Brown: > > On Wed, Aug 07, 2019 at 10:55:01AM +, Koenig, Christian wrote: > >> Am 07.08.19 um 12:41 schrieb Christoph Hellwig: > >>> writeq/readq are prov

Re: [PATCH] nouveau/hmm: map pages after migration

s the source CPU page table entries. This preserves copy on write > semantics. > > Signed-off-by: Ralph Campbell > Cc: Christoph Hellwig > Cc: Jason Gunthorpe > Cc: "Jérôme Glisse" > Cc: Ben Skeggs > --- > > This patch is based on top of Christoph Hellwig

Re: [PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk

On Wed, Aug 07, 2019 at 11:47:22AM -0700, Dan Williams wrote: > > Unrelated to this patch, but what is the point of getting checking > > that the pgmap exists for the page and then immediately releasing it? > > This code has this pattern in several places. > > > > It feels racy > > Agree, not

Re: [PATCH hmm] drm/amdkfd: fix a use after free race with mmu_notififer unregister

Btw, who maintains amkfd these days? MAINTAINERS still lists Oded, but he seems to have moved on to Habanalabs and maintains that drivers now while not having any action on amdkfd for over a year. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org

[PATCH 09/15] mm: don't abuse pte_index() in hmm_vma_handle_pmd

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

  1   2   3   4   >