Mailing List Archive

[PATCH 1/3] swiotlb: Warn on allocation failure in swiotlb_alloc_coherent
From: Joerg Roedel <jroedel@suse.de>

Print a warning when all allocation tries have been failed
and the function is about to return NULL. This prepares for
calling the function with __GFP_NOWARN to suppress
allocation failure warnings before all fall-backs have
failed.

Signed-off-by: Joerg Roedel <jroedel@suse.de>
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
lib/swiotlb.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 4abda07..e0e9212 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -655,7 +655,7 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size,
*/
phys_addr_t paddr = map_single(hwdev, 0, size, DMA_FROM_DEVICE);
if (paddr == SWIOTLB_MAP_ERROR)
- return NULL;
+ goto err_warn;

ret = phys_to_virt(paddr);
dev_addr = phys_to_dma(hwdev, paddr);
@@ -669,7 +669,7 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size,
/* DMA_TO_DEVICE to avoid memcpy in unmap_single */
swiotlb_tbl_unmap_single(hwdev, paddr,
size, DMA_TO_DEVICE);
- return NULL;
+ goto err_warn;
}
}

@@ -677,6 +677,13 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size,
memset(ret, 0, size);

return ret;
+
+err_warn:
+ pr_warn("swiotlb: coherent allocation failed for device %s size=%zu\n",
+ dev_name(hwdev), size);
+ dump_stack();
+
+ return NULL;
}
EXPORT_SYMBOL(swiotlb_alloc_coherent);

--
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] swiotlb: Warn on allocation failure in swiotlb_alloc_coherent [ In reply to ]
On Tue, Jan 06, 2015 at 03:51:12PM +0100, Joerg Roedel wrote:
> From: Joerg Roedel <jroedel@suse.de>
>
> Print a warning when all allocation tries have been failed
> and the function is about to return NULL. This prepares for
> calling the function with __GFP_NOWARN to suppress
> allocation failure warnings before all fall-backs have
> failed.
>
> Signed-off-by: Joerg Roedel <jroedel@suse.de>
> Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---

...

> @@ -677,6 +677,13 @@ swiotlb_alloc_coherent(struct device *hwdev, size_t size,
> memset(ret, 0, size);
>
> return ret;
> +
> +err_warn:
> + pr_warn("swiotlb: coherent allocation failed for device %s size=%zu\n",
> + dev_name(hwdev), size);
> + dump_stack();

Are we really sure we want to be that noisy about it? What happens if
that fails, we can't do DMA anymore or should we free some precious DMA
memory, as a compromise?

--
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] swiotlb: Warn on allocation failure in swiotlb_alloc_coherent [ In reply to ]
On Fri, Jan 23, 2015 at 06:04:25PM +0100, Borislav Petkov wrote:
> On Tue, Jan 06, 2015 at 03:51:12PM +0100, Joerg Roedel wrote:
> > +
> > +err_warn:
> > + pr_warn("swiotlb: coherent allocation failed for device %s size=%zu\n",
> > + dev_name(hwdev), size);
> > + dump_stack();
>
> Are we really sure we want to be that noisy about it? What happens if
> that fails, we can't do DMA anymore or should we free some precious DMA
> memory, as a compromise?

Hmm, I don't think there is a way to request drivers to free DMA memory.
What this patch does is to keep the same noisiness as before, just not
from the page allocator but from the very end of the DMA allocation
process, when everything failed.
We can of course discuss whether this is too noisy and put some kind of
ratelimit around.


Joerg

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/