From: Ian Abbott <abbotti@mev.co.uk>
To: Christoph Hellwig <hch@lst.de>, Greg KH <gregkh@linuxfoundation.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <maxime.ripard@bootlin.com>,
Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
Daniel Vetter <daniel@ffwll.ch>,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
H Hartley Sweeten <hsweeten@visionengravers.com>,
devel@driverdev.osuosl.org, linux-s390@vger.kernel.org,
Intel Linux Wireless <linuxwifi@intel.com>,
linux-rdma@vger.kernel.org, netdev@vger.kernel.org,
intel-gfx@lists.freedesktop.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, iommu@lists.linux-foundation.org,
"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
linux-media@vger.kernel.org
Subject: Re: [PATCH 12/16] staging/comedi: mark as broken
Date: Mon, 17 Jun 2019 14:15:43 +0100 [thread overview]
Message-ID: <60c6af3d-d8e4-5745-8d2b-9791a2f4ff56@mev.co.uk> (raw)
In-Reply-To: <20190614153428.GA10008@lst.de>
On 14/06/2019 16:34, Christoph Hellwig wrote:
> On Fri, Jun 14, 2019 at 05:30:32PM +0200, Greg KH wrote:
>> On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
>>> On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
>>>> Perhaps a hint as to how we can fix this up? This is the first time
>>>> I've heard of the comedi code not handling dma properly.
>>>
>>> It can be fixed by:
>>>
>>> a) never calling virt_to_page (or vmalloc_to_page for that matter)
>>> on dma allocation
>>> b) never remapping dma allocation with conflicting cache modes
>>> (no remapping should be doable after a) anyway).
>>
>> Ok, fair enough, have any pointers of drivers/core code that does this
>> correctly? I can put it on my todo list, but might take a week or so...
>
> Just about everyone else. They just need to remove the vmap and
> either do one large allocation, or live with the fact that they need
> helpers to access multiple array elements instead of one net vmap,
> which most of the users already seem to do anyway, with just a few
> using the vmap (which might explain why we didn't see blowups yet).
Avoiding the vmap in comedi should be do-able as it already has other
means to get at the buffer pages.
When comedi makes the buffer from DMA coherent memory, it currently
allocates it as a series of page-sized chunks. That cannot be mmap'ed
in one go with dma_mmap_coherent(), so I see the following solutions.
1. Change the buffer allocation to allocate a single chunk of DMA
coherent memory and use dma_mmap_coherent() to mmap it.
2. Call dma_mmap_coherent() in a loop, adjusting vma->vm_start and
vma->vm_end for each iteration (vma->vm_pgoff will be 0), and restoring
the vma->vm_start and vma->vm_end at the end.
I'm not sure if 2 is a legal option.
--
-=( Ian Abbott <abbotti@mev.co.uk> || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address: )=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
WARNING: multiple messages have this Message-ID (diff)
From: Ian Abbott <abbotti@mev.co.uk>
To: Christoph Hellwig <hch@lst.de>, Greg KH <gregkh@linuxfoundation.org>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
devel@driverdev.osuosl.org, linux-s390@vger.kernel.org,
linux-rdma@vger.kernel.org, David Airlie <airlied@linux.ie>,
linux-media@vger.kernel.org,
Intel Linux Wireless <linuxwifi@intel.com>,
intel-gfx@lists.freedesktop.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Sean Paul <sean@poorly.run>,
"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org,
H Hartley Sweeten <hsweeten@visionengravers.com>,
iommu@lists.linux-foundation.org, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 12/16] staging/comedi: mark as broken
Date: Mon, 17 Jun 2019 14:15:43 +0100 [thread overview]
Message-ID: <60c6af3d-d8e4-5745-8d2b-9791a2f4ff56@mev.co.uk> (raw)
In-Reply-To: <20190614153428.GA10008@lst.de>
On 14/06/2019 16:34, Christoph Hellwig wrote:
> On Fri, Jun 14, 2019 at 05:30:32PM +0200, Greg KH wrote:
>> On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
>>> On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
>>>> Perhaps a hint as to how we can fix this up? This is the first time
>>>> I've heard of the comedi code not handling dma properly.
>>>
>>> It can be fixed by:
>>>
>>> a) never calling virt_to_page (or vmalloc_to_page for that matter)
>>> on dma allocation
>>> b) never remapping dma allocation with conflicting cache modes
>>> (no remapping should be doable after a) anyway).
>>
>> Ok, fair enough, have any pointers of drivers/core code that does this
>> correctly? I can put it on my todo list, but might take a week or so...
>
> Just about everyone else. They just need to remove the vmap and
> either do one large allocation, or live with the fact that they need
> helpers to access multiple array elements instead of one net vmap,
> which most of the users already seem to do anyway, with just a few
> using the vmap (which might explain why we didn't see blowups yet).
Avoiding the vmap in comedi should be do-able as it already has other
means to get at the buffer pages.
When comedi makes the buffer from DMA coherent memory, it currently
allocates it as a series of page-sized chunks. That cannot be mmap'ed
in one go with dma_mmap_coherent(), so I see the following solutions.
1. Change the buffer allocation to allocate a single chunk of DMA
coherent memory and use dma_mmap_coherent() to mmap it.
2. Call dma_mmap_coherent() in a loop, adjusting vma->vm_start and
vma->vm_end for each iteration (vma->vm_pgoff will be 0), and restoring
the vma->vm_start and vma->vm_end at the end.
I'm not sure if 2 is a legal option.
--
-=( Ian Abbott <abbotti@mev.co.uk> || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address: )=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
WARNING: multiple messages have this Message-ID (diff)
From: Ian Abbott <abbotti@mev.co.uk>
To: Christoph Hellwig <hch@lst.de>, Greg KH <gregkh@linuxfoundation.org>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
devel@driverdev.osuosl.org, linux-s390@vger.kernel.org,
linux-rdma@vger.kernel.org, David Airlie <airlied@linux.ie>,
linux-media@vger.kernel.org,
Intel Linux Wireless <linuxwifi@intel.com>,
intel-gfx@lists.freedesktop.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Sean Paul <sean@poorly.run>,
"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org,
H Hartley Sweeten <hsweeten@visionengravers.com>,
iommu@lists.linux-foundation.org, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 12/16] staging/comedi: mark as broken
Date: Mon, 17 Jun 2019 14:15:43 +0100 [thread overview]
Message-ID: <60c6af3d-d8e4-5745-8d2b-9791a2f4ff56@mev.co.uk> (raw)
In-Reply-To: <20190614153428.GA10008@lst.de>
On 14/06/2019 16:34, Christoph Hellwig wrote:
> On Fri, Jun 14, 2019 at 05:30:32PM +0200, Greg KH wrote:
>> On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
>>> On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
>>>> Perhaps a hint as to how we can fix this up? This is the first time
>>>> I've heard of the comedi code not handling dma properly.
>>>
>>> It can be fixed by:
>>>
>>> a) never calling virt_to_page (or vmalloc_to_page for that matter)
>>> on dma allocation
>>> b) never remapping dma allocation with conflicting cache modes
>>> (no remapping should be doable after a) anyway).
>>
>> Ok, fair enough, have any pointers of drivers/core code that does this
>> correctly? I can put it on my todo list, but might take a week or so...
>
> Just about everyone else. They just need to remove the vmap and
> either do one large allocation, or live with the fact that they need
> helpers to access multiple array elements instead of one net vmap,
> which most of the users already seem to do anyway, with just a few
> using the vmap (which might explain why we didn't see blowups yet).
Avoiding the vmap in comedi should be do-able as it already has other
means to get at the buffer pages.
When comedi makes the buffer from DMA coherent memory, it currently
allocates it as a series of page-sized chunks. That cannot be mmap'ed
in one go with dma_mmap_coherent(), so I see the following solutions.
1. Change the buffer allocation to allocate a single chunk of DMA
coherent memory and use dma_mmap_coherent() to mmap it.
2. Call dma_mmap_coherent() in a loop, adjusting vma->vm_start and
vma->vm_end for each iteration (vma->vm_pgoff will be 0), and restoring
the vma->vm_start and vma->vm_end at the end.
I'm not sure if 2 is a legal option.
--
-=( Ian Abbott <abbotti@mev.co.uk> || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address: )=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Ian Abbott <abbotti@mev.co.uk>
To: Christoph Hellwig <hch@lst.de>, Greg KH <gregkh@linuxfoundation.org>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
devel@driverdev.osuosl.org, linux-s390@vger.kernel.org,
linux-rdma@vger.kernel.org, David Airlie <airlied@linux.ie>,
linux-media@vger.kernel.org,
Intel Linux Wireless <linuxwifi@intel.com>,
intel-gfx@lists.freedesktop.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Sean Paul <sean@poorly.run>,
"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org,
H Hartley Sweeten <hsweeten@visionengravers.com>,
iommu@lists.linux-foundation.org, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 12/16] staging/comedi: mark as broken
Date: Mon, 17 Jun 2019 14:15:43 +0100 [thread overview]
Message-ID: <60c6af3d-d8e4-5745-8d2b-9791a2f4ff56@mev.co.uk> (raw)
In-Reply-To: <20190614153428.GA10008@lst.de>
On 14/06/2019 16:34, Christoph Hellwig wrote:
> On Fri, Jun 14, 2019 at 05:30:32PM +0200, Greg KH wrote:
>> On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote:
>>> On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote:
>>>> Perhaps a hint as to how we can fix this up? This is the first time
>>>> I've heard of the comedi code not handling dma properly.
>>>
>>> It can be fixed by:
>>>
>>> a) never calling virt_to_page (or vmalloc_to_page for that matter)
>>> on dma allocation
>>> b) never remapping dma allocation with conflicting cache modes
>>> (no remapping should be doable after a) anyway).
>>
>> Ok, fair enough, have any pointers of drivers/core code that does this
>> correctly? I can put it on my todo list, but might take a week or so...
>
> Just about everyone else. They just need to remove the vmap and
> either do one large allocation, or live with the fact that they need
> helpers to access multiple array elements instead of one net vmap,
> which most of the users already seem to do anyway, with just a few
> using the vmap (which might explain why we didn't see blowups yet).
Avoiding the vmap in comedi should be do-able as it already has other
means to get at the buffer pages.
When comedi makes the buffer from DMA coherent memory, it currently
allocates it as a series of page-sized chunks. That cannot be mmap'ed
in one go with dma_mmap_coherent(), so I see the following solutions.
1. Change the buffer allocation to allocate a single chunk of DMA
coherent memory and use dma_mmap_coherent() to mmap it.
2. Call dma_mmap_coherent() in a loop, adjusting vma->vm_start and
vma->vm_end for each iteration (vma->vm_pgoff will be 0), and restoring
the vma->vm_start and vma->vm_end at the end.
I'm not sure if 2 is a legal option.
--
-=( Ian Abbott <abbotti@mev.co.uk> || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address: )=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-06-17 13:21 UTC|newest]
Thread overview: 165+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-14 13:47 use exact allocation for dma coherent memory Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 01/16] media: videobuf-dma-contig: use dma_mmap_coherent Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 02/16] drm/ati_pcigart: stop using drm_pci_alloc Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 03/16] drm/i915: " Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 16:45 ` [Intel-gfx] " Ville Syrjälä
2019-06-14 16:45 ` Ville Syrjälä
2019-06-14 16:45 ` Ville Syrjälä
2019-06-14 16:45 ` Ville Syrjälä
2019-06-14 16:45 ` Ville Syrjälä
2019-06-14 13:47 ` [PATCH 04/16] drm: move drm_pci_{alloc,free} to drm_legacy Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 04/16] drm: move drm_pci_{alloc, free} " Christoph Hellwig
2019-06-14 13:47 ` [PATCH 05/16] drm: don't mark pages returned from drm_pci_alloc reserved Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 06/16] drm: don't pass __GFP_COMP to dma_alloc_coherent in drm_pci_alloc Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 07/16] IB/hfi1: stop passing bogus gfp flags arguments to dma_alloc_coherent Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 08/16] IB/qib: " Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 09/16] cnic: " Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 10/16] iwlwifi: " Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 11/16] s390/ism: " Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 12/16] staging/comedi: mark as broken Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 14:02 ` Greg KH
2019-06-14 14:02 ` Greg KH
2019-06-14 14:02 ` Greg KH
2019-06-14 14:02 ` Greg KH
2019-06-14 14:48 ` Christoph Hellwig
2019-06-14 14:48 ` Christoph Hellwig
2019-06-14 14:48 ` Christoph Hellwig
2019-06-14 14:48 ` Christoph Hellwig
2019-06-14 15:30 ` Greg KH
2019-06-14 15:30 ` Greg KH
2019-06-14 15:30 ` Greg KH
2019-06-14 15:30 ` Greg KH
2019-06-14 15:34 ` Christoph Hellwig
2019-06-14 15:34 ` Christoph Hellwig
2019-06-14 15:34 ` Christoph Hellwig
2019-06-14 15:34 ` Christoph Hellwig
2019-06-17 13:15 ` Ian Abbott [this message]
2019-06-17 13:15 ` Ian Abbott
2019-06-17 13:15 ` Ian Abbott
2019-06-17 13:15 ` Ian Abbott
2019-06-14 13:47 ` [PATCH 13/16] mm: rename alloc_pages_exact_nid to alloc_pages_exact_node Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 14/16] mm: use alloc_pages_exact_node to implement alloc_pages_exact Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 15/16] dma-mapping: clear __GFP_COMP in dma_alloc_attrs Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` [PATCH 16/16] dma-mapping: use exact allocation in dma_alloc_contiguous Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 13:47 ` Christoph Hellwig
2019-06-14 14:15 ` David Laight
2019-06-14 14:15 ` David Laight
2019-06-14 14:15 ` David Laight
2019-06-14 14:15 ` David Laight
2019-06-14 14:50 ` 'Christoph Hellwig'
2019-06-14 14:50 ` 'Christoph Hellwig'
2019-06-14 14:50 ` 'Christoph Hellwig'
2019-06-14 14:50 ` 'Christoph Hellwig'
2019-06-14 15:01 ` David Laight
2019-06-14 15:01 ` David Laight
2019-06-14 15:01 ` David Laight
2019-06-14 15:01 ` David Laight
2019-06-14 15:05 ` 'Christoph Hellwig'
2019-06-14 15:05 ` 'Christoph Hellwig'
2019-06-14 15:05 ` 'Christoph Hellwig'
2019-06-14 15:05 ` 'Christoph Hellwig'
2019-06-14 15:05 ` Robin Murphy
2019-06-14 15:05 ` Robin Murphy
2019-06-14 15:05 ` Robin Murphy
2019-06-14 15:05 ` Robin Murphy
2019-06-14 15:08 ` 'Christoph Hellwig'
2019-06-14 15:08 ` 'Christoph Hellwig'
2019-06-14 15:08 ` 'Christoph Hellwig'
2019-06-14 15:08 ` 'Christoph Hellwig'
2019-06-14 15:16 ` David Laight
2019-06-14 15:16 ` David Laight
2019-06-14 15:16 ` David Laight
2019-06-14 15:16 ` David Laight
2019-06-17 8:21 ` use exact allocation for dma coherent memory Dan Carpenter
2019-06-17 8:21 ` Dan Carpenter
2019-06-17 8:21 ` Dan Carpenter
2019-06-17 8:21 ` Dan Carpenter
2019-06-17 8:33 ` Christoph Hellwig
2019-06-17 8:33 ` Christoph Hellwig
2019-06-17 8:33 ` Christoph Hellwig
2019-06-17 8:33 ` Christoph Hellwig
2019-06-19 16:29 ` Jason Gunthorpe
2019-06-19 16:29 ` Jason Gunthorpe
2019-06-19 16:29 ` Jason Gunthorpe
2019-06-19 16:29 ` Jason Gunthorpe
2019-06-19 16:29 ` Jason Gunthorpe
2019-06-20 10:51 ` Christoph Hellwig
2019-06-20 10:51 ` Christoph Hellwig
2019-06-20 10:51 ` Christoph Hellwig
2019-06-20 10:51 ` Christoph Hellwig
2019-06-20 10:51 ` Christoph Hellwig
2019-07-01 8:48 ` Christoph Hellwig
2019-07-01 8:48 ` Christoph Hellwig
2019-07-01 8:48 ` Christoph Hellwig
2019-07-01 8:48 ` Christoph Hellwig
2019-07-02 9:48 ` Arend Van Spriel
2019-07-02 9:48 ` Arend Van Spriel
2019-07-02 9:48 ` Arend Van Spriel via iommu
2019-07-02 9:48 ` Arend Van Spriel
2019-07-08 18:43 ` Christoph Hellwig
2019-07-08 18:43 ` Christoph Hellwig
2019-07-08 18:43 ` Christoph Hellwig
2019-07-08 18:43 ` Christoph Hellwig
2019-07-08 18:43 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60c6af3d-d8e4-5745-8d2b-9791a2f4ff56@mev.co.uk \
--to=abbotti@mev.co.uk \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=devel@driverdev.osuosl.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=hsweeten@visionengravers.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linuxwifi@intel.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=maxime.ripard@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=sean@poorly.run \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.