[PATCH] mm/dmapool: switch from strlcpy to strscpy

strlcpy is marked as deprecated in Documentation/process/deprecated.rst, and there is no functional difference when the caller expects truncation (when not checking the return value). strscpy is relatively better as it also avoids scanning the whole source string. Signed-off-by: Zhiyuan Dai ---

[PATCH 1/2] mm/dmapool: Use might_alloc()

Now that my little helper has landed, use it more. On top of the existing check this also uses lockdep through the fs_reclaim annotations. Signed-off-by: Daniel Vetter Cc: Andrew Morton Cc: linux...@kvack.org -- v2: git add everything ... :-/ --- mm/dmapool.c | 3 ++- 1 file changed, 2

[PATCH 1/2] mm/dmapool: Use might_alloc()

Now that my little helper has landed, use it more. On top of the existing check this also uses lockdep through the fs_reclaim annotations. Signed-off-by: Daniel Vetter Cc: Andrew Morton Cc: linux...@kvack.org --- mm/dmapool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 26/28] dmapool: add dma_alloc_pages support

Add an new variant of a dmapool that uses non-coherent memory from dma_alloc_pages. Unlike the existing mempool_create this one initialized a pool allocated by the caller to avoid a pointless extra allocation. At some point it might be worth to also switch the coherent allocation over

Re: dmapool regression in next

dma_addr_t dma); > > >> > > >> With the old code, the 'dma' value had to be correct for use with > > >> pool_find_page(), or else you would get an error.  If the 'vaddr' value > > >> was incorrect, it would corrupt the dmapool freelist, but you wo

Re: dmapool regression in next

dma_addr_t dma); > > >> > > >> With the old code, the 'dma' value had to be correct for use with > > >> pool_find_page(), or else you would get an error.  If the 'vaddr' value > > >> was incorrect, it would corrupt the dmapool freelist, but you wo

Re: dmapool regression in next

for use with > >> pool_find_page(), or else you would get an error.  If the 'vaddr' value > >> was incorrect, it would corrupt the dmapool freelist, but you wouldn't > >> get an error unless DMAPOOL_DEBUG was enabled. > >> > >> With my patch applied, 'va

Re: dmapool regression in next

for use with > >> pool_find_page(), or else you would get an error.  If the 'vaddr' value > >> was incorrect, it would corrupt the dmapool freelist, but you wouldn't > >> get an error unless DMAPOOL_DEBUG was enabled. > >> > >> With my patch applied, 'va

Re: dmapool regression in next

get an error.  If the 'vaddr' value >> was incorrect, it would corrupt the dmapool freelist, but you wouldn't >> get an error unless DMAPOOL_DEBUG was enabled. >> >> With my patch applied, 'vaddr' has to be correct for virt_to_page().  My >> code also checks that 'dma' is c

Re: dmapool regression in next

get an error.  If the 'vaddr' value >> was incorrect, it would corrupt the dmapool freelist, but you wouldn't >> get an error unless DMAPOOL_DEBUG was enabled. >> >> With my patch applied, 'vaddr' has to be correct for virt_to_page().  My >> code also checks that 'dma' is c

Re: dmapool regression in next

de, the 'dma' value had to be correct for use with pool_find_page(), or else you would get an error.  If the 'vaddr' value was incorrect, it would corrupt the dmapool freelist, but you wouldn't get an error unless DMAPOOL_DEBUG was enabled. With my patch applied, 'vaddr' has to be correct for virt_to_page(

Re: dmapool regression in next

de, the 'dma' value had to be correct for use with pool_find_page(), or else you would get an error.  If the 'vaddr' value was incorrect, it would corrupt the dmapool freelist, but you wouldn't get an error unless DMAPOOL_DEBUG was enabled. With my patch applied, 'vaddr' has to be correct for virt_to_page(

Re: dmapool regression in next

s/12/logs/serial0 > > Best regards, > Krzysztof > Here is the prototype: void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t dma); With the old code, the 'dma' value had to be correct for use with pool_find_page(), or else you would get an error.  If the 'vaddr' value was inco

Re: dmapool regression in next

s/12/logs/serial0 > > Best regards, > Krzysztof > Here is the prototype: void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t dma); With the old code, the 'dma' value had to be correct for use with pool_find_page(), or else you would get an error.  If the 'vaddr' value was inco

Re: dmapool regression in next

On Thu, 6 Dec 2018 at 02:31, Tony Lindgren wrote: > > Hi, > > Looks like with commit 26abe88e830d ("mm/dmapool.c: improve scalability > of dma_pool_free()") I'm now getting spammed with lots of "(bad vaddr)" > on at least omap4 pandaboard, see below. > > Any ideas what might be going wrong? > >

Re: dmapool regression in next

On Thu, 6 Dec 2018 at 02:31, Tony Lindgren wrote: > > Hi, > > Looks like with commit 26abe88e830d ("mm/dmapool.c: improve scalability > of dma_pool_free()") I'm now getting spammed with lots of "(bad vaddr)" > on at least omap4 pandaboard, see below. > > Any ideas what might be going wrong? > >

dmapool regression in next

Hi, Looks like with commit 26abe88e830d ("mm/dmapool.c: improve scalability of dma_pool_free()") I'm now getting spammed with lots of "(bad vaddr)" on at least omap4 pandaboard, see below. Any ideas what might be going wrong? Regards, Tony 8< - omap-dma-engine

dmapool regression in next

Hi, Looks like with commit 26abe88e830d ("mm/dmapool.c: improve scalability of dma_pool_free()") I'm now getting spammed with lots of "(bad vaddr)" on at least omap4 pandaboard, see below. Any ideas what might be going wrong? Regards, Tony 8< - omap-dma-engine

Re: [PATCH] mm: dmapool: Check the dma pool name

On 30 May 2018 at 23:41, Matthew Wilcox wrote: > On Wed, May 30, 2018 at 08:13:27AM -0700, Matthew Wilcox wrote: >> On Wed, May 30, 2018 at 08:14:09PM +0800, Baolin Wang wrote: >> > On 30 May 2018 at 20:01, Matthew Wilcox wrote: >> > > On Wed, May 30, 2018 at 07:28:43PM +0800, Baolin Wang wrote:

Re: [PATCH] mm: dmapool: Check the dma pool name

On 30 May 2018 at 23:41, Matthew Wilcox wrote: > On Wed, May 30, 2018 at 08:13:27AM -0700, Matthew Wilcox wrote: >> On Wed, May 30, 2018 at 08:14:09PM +0800, Baolin Wang wrote: >> > On 30 May 2018 at 20:01, Matthew Wilcox wrote: >> > > On Wed, May 30, 2018 at 07:28:43PM +0800, Baolin Wang wrote:

Re: [PATCH] mm: dmapool: Check the dma pool name

On Wed, May 30, 2018 at 08:13:27AM -0700, Matthew Wilcox wrote: > On Wed, May 30, 2018 at 08:14:09PM +0800, Baolin Wang wrote: > > On 30 May 2018 at 20:01, Matthew Wilcox wrote: > > > On Wed, May 30, 2018 at 07:28:43PM +0800, Baolin Wang wrote: > > >> It will be crash if we pass one NULL name

Re: [PATCH] mm: dmapool: Check the dma pool name

On Wed, May 30, 2018 at 08:13:27AM -0700, Matthew Wilcox wrote: > On Wed, May 30, 2018 at 08:14:09PM +0800, Baolin Wang wrote: > > On 30 May 2018 at 20:01, Matthew Wilcox wrote: > > > On Wed, May 30, 2018 at 07:28:43PM +0800, Baolin Wang wrote: > > >> It will be crash if we pass one NULL name

Re: [PATCH] mm: dmapool: Check the dma pool name

On Wed, May 30, 2018 at 08:14:09PM +0800, Baolin Wang wrote: > On 30 May 2018 at 20:01, Matthew Wilcox wrote: > > On Wed, May 30, 2018 at 07:28:43PM +0800, Baolin Wang wrote: > >> It will be crash if we pass one NULL name when creating one dma pool, > >> so we should check the passing name when

Re: [PATCH] mm: dmapool: Check the dma pool name

On Wed, May 30, 2018 at 08:14:09PM +0800, Baolin Wang wrote: > On 30 May 2018 at 20:01, Matthew Wilcox wrote: > > On Wed, May 30, 2018 at 07:28:43PM +0800, Baolin Wang wrote: > >> It will be crash if we pass one NULL name when creating one dma pool, > >> so we should check the passing name when

Re: [PATCH] mm: dmapool: Check the dma pool name

On 30 May 2018 at 20:01, Matthew Wilcox wrote: > On Wed, May 30, 2018 at 07:28:43PM +0800, Baolin Wang wrote: >> It will be crash if we pass one NULL name when creating one dma pool, >> so we should check the passing name when copy it to dma pool. > > NAK. Crashing is the appropriate thing to

Re: [PATCH] mm: dmapool: Check the dma pool name

On 30 May 2018 at 20:01, Matthew Wilcox wrote: > On Wed, May 30, 2018 at 07:28:43PM +0800, Baolin Wang wrote: >> It will be crash if we pass one NULL name when creating one dma pool, >> so we should check the passing name when copy it to dma pool. > > NAK. Crashing is the appropriate thing to

Re: [PATCH] mm: dmapool: Check the dma pool name

On Wed, May 30, 2018 at 07:28:43PM +0800, Baolin Wang wrote: > It will be crash if we pass one NULL name when creating one dma pool, > so we should check the passing name when copy it to dma pool. NAK. Crashing is the appropriate thing to do. Fix the caller to not pass NULL. If you permit NULL

Re: [PATCH] mm: dmapool: Check the dma pool name

On Wed, May 30, 2018 at 07:28:43PM +0800, Baolin Wang wrote: > It will be crash if we pass one NULL name when creating one dma pool, > so we should check the passing name when copy it to dma pool. NAK. Crashing is the appropriate thing to do. Fix the caller to not pass NULL. If you permit NULL

[PATCH] mm: dmapool: Check the dma pool name

It will be crash if we pass one NULL name when creating one dma pool, so we should check the passing name when copy it to dma pool. Moreover this patch replaces kmalloc_node() with kzalloc_node() to make sure the name array of dma pool is initialized in case the passing name is NULL.

[PATCH] mm: dmapool: Check the dma pool name

It will be crash if we pass one NULL name when creating one dma pool, so we should check the passing name when copy it to dma pool. Moreover this patch replaces kmalloc_node() with kzalloc_node() to make sure the name array of dma pool is initialized in case the passing name is NULL.

Re: [PATCH] mm/dmapool: localize page allocations

On 5/17/2018 4:41 PM, Matthew Wilcox wrote: > Let's try a different example. I have a four-socket system with one > NVMe device with lots of hardware queues. Each CPU has its own queue > assigned to it. If I allocate all the PRP metadata on the socket with > the NVMe device attached to it, I'm

Re: [PATCH] mm/dmapool: localize page allocations

On 5/17/2018 4:41 PM, Matthew Wilcox wrote: > Let's try a different example. I have a four-socket system with one > NVMe device with lots of hardware queues. Each CPU has its own queue > assigned to it. If I allocate all the PRP metadata on the socket with > the NVMe device attached to it, I'm

Re: [PATCH] mm/dmapool: localize page allocations

On Thu, May 17, 2018 at 04:05:45PM -0400, Sinan Kaya wrote: > On 5/17/2018 3:46 PM, Matthew Wilcox wrote: > >> Remember that the CPU core that is running this driver is most probably on > >> the same NUMA node as the device itself. > > Umm ... says who? If my process is running on NUMA node 5 and

Re: [PATCH] mm/dmapool: localize page allocations

On Thu, May 17, 2018 at 04:05:45PM -0400, Sinan Kaya wrote: > On 5/17/2018 3:46 PM, Matthew Wilcox wrote: > >> Remember that the CPU core that is running this driver is most probably on > >> the same NUMA node as the device itself. > > Umm ... says who? If my process is running on NUMA node 5 and

Re: [PATCH] mm/dmapool: localize page allocations

On 5/17/2018 3:46 PM, Matthew Wilcox wrote: >> Remember that the CPU core that is running this driver is most probably on >> the same NUMA node as the device itself. > Umm ... says who? If my process is running on NUMA node 5 and I submit > an I/O, it should be allocating from a pool on node 5,

Re: [PATCH] mm/dmapool: localize page allocations

On 5/17/2018 3:46 PM, Matthew Wilcox wrote: >> Remember that the CPU core that is running this driver is most probably on >> the same NUMA node as the device itself. > Umm ... says who? If my process is running on NUMA node 5 and I submit > an I/O, it should be allocating from a pool on node 5,

Re: [PATCH] mm/dmapool: localize page allocations

On Thu, May 17, 2018 at 03:37:21PM -0400, Sinan Kaya wrote: > On 5/17/2018 2:18 PM, Matthew Wilcox wrote: > > On Thu, May 17, 2018 at 01:36:19PM -0400, Sinan Kaya wrote: > >> Try to keep the pool closer to the device's NUMA node by changing kmalloc() > >> to kmalloc_node() and devres_alloc() to

Re: [PATCH] mm/dmapool: localize page allocations

On Thu, May 17, 2018 at 03:37:21PM -0400, Sinan Kaya wrote: > On 5/17/2018 2:18 PM, Matthew Wilcox wrote: > > On Thu, May 17, 2018 at 01:36:19PM -0400, Sinan Kaya wrote: > >> Try to keep the pool closer to the device's NUMA node by changing kmalloc() > >> to kmalloc_node() and devres_alloc() to

Re: [PATCH] mm/dmapool: localize page allocations

On 5/17/2018 2:18 PM, Matthew Wilcox wrote: > On Thu, May 17, 2018 at 01:36:19PM -0400, Sinan Kaya wrote: >> Try to keep the pool closer to the device's NUMA node by changing kmalloc() >> to kmalloc_node() and devres_alloc() to devres_alloc_node(). > Have you measured any performance gains by

Re: [PATCH] mm/dmapool: localize page allocations

On 5/17/2018 2:18 PM, Matthew Wilcox wrote: > On Thu, May 17, 2018 at 01:36:19PM -0400, Sinan Kaya wrote: >> Try to keep the pool closer to the device's NUMA node by changing kmalloc() >> to kmalloc_node() and devres_alloc() to devres_alloc_node(). > Have you measured any performance gains by

Re: [PATCH] mm/dmapool: localize page allocations

On Thu, May 17, 2018 at 01:36:19PM -0400, Sinan Kaya wrote: > Try to keep the pool closer to the device's NUMA node by changing kmalloc() > to kmalloc_node() and devres_alloc() to devres_alloc_node(). Have you measured any performance gains by doing this? The thing is that these allocations are

Re: [PATCH] mm/dmapool: localize page allocations

On Thu, May 17, 2018 at 01:36:19PM -0400, Sinan Kaya wrote: > Try to keep the pool closer to the device's NUMA node by changing kmalloc() > to kmalloc_node() and devres_alloc() to devres_alloc_node(). Have you measured any performance gains by doing this? The thing is that these allocations are

[PATCH] mm/dmapool: localize page allocations

Try to keep the pool closer to the device's NUMA node by changing kmalloc() to kmalloc_node() and devres_alloc() to devres_alloc_node(). Signed-off-by: Sinan Kaya --- mm/dmapool.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/mm/dmapool.c

[PATCH] mm/dmapool: localize page allocations

Try to keep the pool closer to the device's NUMA node by changing kmalloc() to kmalloc_node() and devres_alloc() to devres_alloc_node(). Signed-off-by: Sinan Kaya --- mm/dmapool.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/mm/dmapool.c b/mm/dmapool.c index

Re: [V5, 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode

Oh, I know, I've make a mistake, dmapool doesn't need to change. Huacai -- Original -- From: "Christoph Hellwig"<h...@infradead.org>; Date: Mon, Sep 18, 2017 11:51 PM To: "Robin Murphy"<robin.mur...@arm.com>; Cc: "Hua

Re: [V5, 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode

Oh, I know, I've make a mistake, dmapool doesn't need to change. Huacai -- Original -- From: "Christoph Hellwig"; Date: Mon, Sep 18, 2017 11:51 PM To: "Robin Murphy"; Cc: "Huacai Chen"; "Andrew Morton"; "Fuxin

Re: [V5, 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

On Mon, Sep 18, 2017 at 10:44:54AM +0100, Robin Murphy wrote: > On 18/09/17 05:22, Huacai Chen wrote: > > In non-coherent DMA mode, kernel uses cache flushing operations to > > maintain I/O coherency, so the dmapool objects should be aligned to > > ARCH_DMA_MINALIGN. Otherwis

Re: [V5, 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

On Mon, Sep 18, 2017 at 10:44:54AM +0100, Robin Murphy wrote: > On 18/09/17 05:22, Huacai Chen wrote: > > In non-coherent DMA mode, kernel uses cache flushing operations to > > maintain I/O coherency, so the dmapool objects should be aligned to > > ARCH_DMA_MINALIGN. Otherwis

Re: [PATCH V5 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

Ok, it looks like adding the dma_get_cache_alignment constraint here looks good - but again it should be unconditional.

Re: [PATCH V5 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

Ok, it looks like adding the dma_get_cache_alignment constraint here looks good - but again it should be unconditional.

Re: [V5, 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

On 18/09/17 05:22, Huacai Chen wrote: > In non-coherent DMA mode, kernel uses cache flushing operations to > maintain I/O coherency, so the dmapool objects should be aligned to > ARCH_DMA_MINALIGN. Otherwise, it will cause data corruption, at least > on MIPS: > > Step

Re: [V5, 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

On 18/09/17 05:22, Huacai Chen wrote: > In non-coherent DMA mode, kernel uses cache flushing operations to > maintain I/O coherency, so the dmapool objects should be aligned to > ARCH_DMA_MINALIGN. Otherwise, it will cause data corruption, at least > on MIPS: > > Step

Re: [PATCH V5 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode

To: "Huacai Chen"<che...@lemote.com>; Cc: "Andrew Morton"<a...@linux-foundation.org>; "Fuxin Zhang"<zhan...@lemote.com>; "linux-mm"<linux...@kvack.org>; "linux-kernel"<linux-kernel@vger.kernel.org>; "stable"&l

Re: [PATCH V5 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode

quot;; Cc: "Andrew Morton"; "Fuxin Zhang"; "linux-mm"; "linux-kernel"; "stable"; Subject: Re: [PATCH V5 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode The dmapool code uses dma_alloc_coherent to allocate each element, and dma_a

Re: [PATCH V5 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

The dmapool code uses dma_alloc_coherent to allocate each element, and dma_alloc_coherent must align to ARCH_DMA_MINALIGN already. If you implementation doesn't do that it needs to be fixed.

Re: [PATCH V5 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

The dmapool code uses dma_alloc_coherent to allocate each element, and dma_alloc_coherent must align to ARCH_DMA_MINALIGN already. If you implementation doesn't do that it needs to be fixed.

[PATCH V5 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so the dmapool objects should be aligned to ARCH_DMA_MINALIGN. Otherwise, it will cause data corruption, at least on MIPS: Step 1, dma_map_single Step 2, cache_invalidate (no writeback

[PATCH V5 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so the dmapool objects should be aligned to ARCH_DMA_MINALIGN. Otherwise, it will cause data corruption, at least on MIPS: Step 1, dma_map_single Step 2, cache_invalidate (no writeback

[PATCH V4 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so the dmapool objects should be aligned to ARCH_DMA_MINALIGN. Otherwise, it will cause data corruption, at least on MIPS: Step 1, dma_map_single Step 2, cache_invalidate (no writeback

[PATCH V4 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so the dmapool objects should be aligned to ARCH_DMA_MINALIGN. Otherwise, it will cause data corruption, at least on MIPS: Step 1, dma_map_single Step 2, cache_invalidate (no writeback

Re: [PATCH V3 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode

..@lemote.com>; "linux-mm"<linux...@kvack.org>; "linux-kernel"<linux-kernel@vger.kernel.org>; "stable"<sta...@vger.kernel.org>; Subject: Re: [PATCH V3 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode On Wed, 13 Sep 2017 17:2

Re: [PATCH V3 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN innon-coherent DMA mode

, cache_invalidate (no writeback) may cause data lost. Huacai -- Original -- From: "Andrew Morton"; Date: Thu, Sep 14, 2017 05:52 AM To: "Huacai Chen"; Cc: "Fuxin Zhang"; "linux-mm"; "linux-kernel"; "st

Re: [PATCH V3 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

On Wed, 13 Sep 2017 17:20:51 +0800 Huacai Chen <che...@lemote.com> wrote: > In non-coherent DMA mode, kernel uses cache flushing operations to > maintain I/O coherency, so the dmapool objects should be aligned to > ARCH_DMA_MINALIGN. What are the user-visible effects of this bug?

Re: [PATCH V3 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

On Wed, 13 Sep 2017 17:20:51 +0800 Huacai Chen wrote: > In non-coherent DMA mode, kernel uses cache flushing operations to > maintain I/O coherency, so the dmapool objects should be aligned to > ARCH_DMA_MINALIGN. What are the user-visible effects of this bug?

[PATCH V3 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so the dmapool objects should be aligned to ARCH_DMA_MINALIGN. Cc: sta...@vger.kernel.org Signed-off-by: Huacai Chen <che...@lemote.com> --- mm/dmapool.c | 3 +++ 1 file changed, 3 insertions(+)

[PATCH V3 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so the dmapool objects should be aligned to ARCH_DMA_MINALIGN. Cc: sta...@vger.kernel.org Signed-off-by: Huacai Chen --- mm/dmapool.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/dmapool.c b

[PATCH V2 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so the dmapool objects should be aligned to ARCH_DMA_MINALIGN. Cc: sta...@vger.kernel.org Signed-off-by: Huacai Chen <che...@lemote.com> --- mm/dmapool.c | 3 +++ 1 file changed, 3 insertions(+)

[PATCH V2 2/3] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so the dmapool objects should be aligned to ARCH_DMA_MINALIGN. Cc: sta...@vger.kernel.org Signed-off-by: Huacai Chen --- mm/dmapool.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/dmapool.c b

Re: [PATCH 1/2] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

Hi Huacai, [auto build test WARNING on mmotm/master] [also build test WARNING on v4.13 next-20170908] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Huacai-Chen/mm-dmapool-Align

Re: [PATCH 1/2] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

Hi Huacai, [auto build test WARNING on mmotm/master] [also build test WARNING on v4.13 next-20170908] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Huacai-Chen/mm-dmapool-Align

Re: [PATCH 1/2] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

Hi Huacai, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.13 next-20170908] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Huacai-Chen/mm-dmapool-Align

Re: [PATCH 1/2] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

Hi Huacai, [auto build test ERROR on mmotm/master] [also build test ERROR on v4.13 next-20170908] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Huacai-Chen/mm-dmapool-Align

[PATCH 1/2] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so the dmapool objects should be aligned to ARCH_DMA_MINALIGN. Cc: sta...@vger.kernel.org Signed-off-by: Huacai Chen <che...@lemote.com> --- mm/dmapool.c | 3 +++ 1 file changed, 3 insertions(+)

[PATCH 1/2] mm: dmapool: Align to ARCH_DMA_MINALIGN in non-coherent DMA mode

In non-coherent DMA mode, kernel uses cache flushing operations to maintain I/O coherency, so the dmapool objects should be aligned to ARCH_DMA_MINALIGN. Cc: sta...@vger.kernel.org Signed-off-by: Huacai Chen --- mm/dmapool.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/dmapool.c b

[PATCH] mm: dmapool: Fixed following warnings

From: AshishKalra WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'. WARNING: Missing a blank line after declarations Warning were detected with checkpatch.pl

[PATCH] mm: dmapool: Fixed following warnings

From: AshishKalra WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'. WARNING: Missing a blank line after declarations Warning were detected with checkpatch.pl Signed-off-by: AshishKalra

[PATCH 1/4] dmapool: Fix overflow condition in pool_find_page

If a DMA pool lies at the very top of the dma_addr_t range (as may happen with an IOMMU involved), the calculated end address of the pool wraps around to zero, and page lookup always fails. Tweak the relevant calculation to be overflow-proof. Signed-off-by: Robin Murphy --- mm/dmapool.c | 2 +-

[PATCH 1/4] dmapool: Fix overflow condition in pool_find_page

If a DMA pool lies at the very top of the dma_addr_t range (as may happen with an IOMMU involved), the calculated end address of the pool wraps around to zero, and page lookup always fails. Tweak the relevant calculation to be overflow-proof. Signed-off-by: Robin Murphy ---

Re: [RFC][PATCH 3/5] mm/dmapool: allow NULL `pool' pointer in dma_pool_destroy()

On Tue, 9 Jun 2015, Sergey Senozhatsky wrote: > dma_pool_destroy() does not tolerate a NULL dma_pool pointer > argument and performs a NULL-pointer dereference. This requires > additional attention and effort from developers/reviewers and > forces all dma_pool_destroy() callers to do a NULL check

Re: [RFC][PATCH 3/5] mm/dmapool: allow NULL `pool' pointer in dma_pool_destroy()

On Tue, 9 Jun 2015, Sergey Senozhatsky wrote: dma_pool_destroy() does not tolerate a NULL dma_pool pointer argument and performs a NULL-pointer dereference. This requires additional attention and effort from developers/reviewers and forces all dma_pool_destroy() callers to do a NULL check

[RFC][PATCH 3/5] mm/dmapool: allow NULL `pool' pointer in dma_pool_destroy()

dma_pool_destroy() does not tolerate a NULL dma_pool pointer argument and performs a NULL-pointer dereference. This requires additional attention and effort from developers/reviewers and forces all dma_pool_destroy() callers to do a NULL check if (pool)

[RFC][PATCH 3/5] mm/dmapool: allow NULL `pool' pointer in dma_pool_destroy()

dma_pool_destroy() does not tolerate a NULL dma_pool pointer argument and performs a NULL-pointer dereference. This requires additional attention and effort from developers/reviewers and forces all dma_pool_destroy() callers to do a NULL check if (pool)

[PATCH] dmapool: Declare struct device

dmapool uses struct device in function arguments but relies on an implicit inclusion to declare struct device causing warnings in some configurations: include/linux/dmapool.h:31:7: warning: 'struct device' declared inside parameter list Fix this by adding a struct device declaration to the file

[PATCH] dmapool: Declare struct device

dmapool uses struct device in function arguments but relies on an implicit inclusion to declare struct device causing warnings in some configurations: include/linux/dmapool.h:31:7: warning: 'struct device' declared inside parameter list Fix this by adding a struct device declaration to the file

[PATCH] MM: dmapool: Fixed a brace coding style issue

Removed 3 brace coding style for any arm of this statement Signed-off-by: Paul McQuade --- mm/dmapool.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/mm/dmapool.c b/mm/dmapool.c index ba8019b..8f4a79a 100644 --- a/mm/dmapool.c +++ b/mm/dmapool.c @@ -133,28

Re: [PATCH] MM: dmapool: Fixed a brace coding style issue

On Tue, 2014-09-30 at 21:49 +0100, Paul McQuade wrote: > From 33890970bfffc2bd64b307c41e5c1c92aaba8a2e Mon Sep 17 00:00:00 2001 > From: Paul McQuade > Date: Tue, 30 Sep 2014 21:39:37 +0100 > Subject: [PATCH] MM: dmapool: Fixed a brace coding style issue > > Removed 3 brace co

Re: [PATCH] MM: dmapool: Fixed a brace coding style issue

On Tue, 2014-09-30 at 21:49 +0100, Paul McQuade wrote: From 33890970bfffc2bd64b307c41e5c1c92aaba8a2e Mon Sep 17 00:00:00 2001 From: Paul McQuade paulmcq...@gmail.com Date: Tue, 30 Sep 2014 21:39:37 +0100 Subject: [PATCH] MM: dmapool: Fixed a brace coding style issue Removed 3 brace coding

[PATCH] MM: dmapool: Fixed a brace coding style issue

Removed 3 brace coding style for any arm of this statement Signed-off-by: Paul McQuade paulmcq...@gmail.com --- mm/dmapool.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/mm/dmapool.c b/mm/dmapool.c index ba8019b..8f4a79a 100644 --- a/mm/dmapool.c +++

[PATCH] MM: dmapool: Fixed a brace coding style issue

>From 33890970bfffc2bd64b307c41e5c1c92aaba8a2e Mon Sep 17 00:00:00 2001 From: Paul McQuade Date: Tue, 30 Sep 2014 21:39:37 +0100 Subject: [PATCH] MM: dmapool: Fixed a brace coding style issue Removed 3 brace coding style for any arm of this statement Signed-off-by: Paul McQuade ---

[PATCH] MM: dmapool: Fixed a brace coding style issue

From 33890970bfffc2bd64b307c41e5c1c92aaba8a2e Mon Sep 17 00:00:00 2001 From: Paul McQuade paulmcq...@gmail.com Date: Tue, 30 Sep 2014 21:39:37 +0100 Subject: [PATCH] MM: dmapool: Fixed a brace coding style issue Removed 3 brace coding style for any arm of this statement Signed-off-by: Paul

[PATCH v2] mm: dmapool: add/remove sysfs file outside of the pool lock lock

cat /sys/…/pools followed by removal the device leads to: |== |[ INFO: possible circular locking dependency detected ] |3.17.0-rc4+ #1498 Not tainted |--- |rmmod/2505 is trying to acquire lock:

[PATCH v2] mm: dmapool: add/remove sysfs file outside of the pool lock lock

cat /sys/…/pools followed by removal the device leads to: |== |[ INFO: possible circular locking dependency detected ] |3.17.0-rc4+ #1498 Not tainted |--- |rmmod/2505 is trying to acquire lock:

Re: [PATCH] mm: dmapool: add/remove sysfs file outside of the pool lock

. Then when this process runs, the file gets removed again. So >we'll get a nasty warning from device_create_file() (I assume) and the >dma_pool_create() call will fail. Please note that this file is _per_ device. I wouldn't assume that you create & destroy over and over again for a single device. But

Re: [PATCH] mm: dmapool: add/remove sysfs file outside of the pool lock

. There's probably a similar race in the destroy()-interrupts-create() path but I'm lazy. +if (empty) +device_remove_file(pool-dev, dev_attr_pools); This problem is pretty ugly. It's a bit surprising that it hasn't happened elsewhere. Perhaps this is because dmapool went

Re: [PATCH] mm: dmapool: add/remove sysfs file outside of the pool lock

evice_create_file() (I assume) and the dma_pool_create() call will fail. There's probably a similar race in the destroy()-interrupts-create() path but I'm lazy. > + if (empty) > + device_remove_file(pool->dev, _attr_pools); > This problem is pretty ugly. It's a bit su

Re: [PATCH] mm: dmapool: add/remove sysfs file outside of the pool lock

ugly. It's a bit surprising that it hasn't happened elsewhere. Perhaps this is because dmapool went and broke the sysfs rules and has multiple values in a single sysfs file. This causes dmapool to walk a list under kernfs_lock and that list walk requires a lock. And it's too late to fix

[PATCH] mm: dmapool: add/remove sysfs file outside of the pool lock

cat /sys/…/pools followed by removal the device leads to: |== |[ INFO: possible circular locking dependency detected ] |3.17.0-rc4+ #1498 Not tainted |--- |rmmod/2505 is trying to acquire lock:

[PATCH] mm: dmapool: add/remove sysfs file outside of the pool lock

cat /sys/…/pools followed by removal the device leads to: |== |[ INFO: possible circular locking dependency detected ] |3.17.0-rc4+ #1498 Not tainted |--- |rmmod/2505 is trying to acquire lock:

Re: [PATCH] dmapool: remove redundant NULL check for dev in dma_pool_create()

2014-05-01 6:19 GMT+09:00, Andrew Morton : > On Tue, 29 Apr 2014 11:53:10 +0900 Daeseok Youn > wrote: > >> "dev" cannot be NULL because it is already checked before >> calling dma_pool_create(). >> >> Signed-off-by: Daeseok Youn >> --- >> If dev can be NULL, it has NULL deferencing when

Re: [PATCH] dmapool: remove redundant NULL check for dev in dma_pool_create()

2014-05-01 6:19 GMT+09:00, Andrew Morton a...@linux-foundation.org: On Tue, 29 Apr 2014 11:53:10 +0900 Daeseok Youn daeseok.y...@gmail.com wrote: dev cannot be NULL because it is already checked before calling dma_pool_create(). Signed-off-by: Daeseok Youn daeseok.y...@gmail.com --- If

  1   2   3   >