Re: [PATCH] dmaengine: async_xor, fix zero address issue when xorhighmem page

[Dan Williams]

2012/1/10 Shi Xuelin-B29237 <B29237@xxxxxxxxxxxxx>:
> Hello Dan Williams,
>
> Do you have any comment about this patch?

Hi, sorrry for the delay.

>
> Thanks,
> Forrest
>
> -----Original Message-----
> From: Shi Xuelin-B29237
> Sent: 2011å12æ27æ 14:31
> To: vinod.koul@xxxxxxxxx; dan.j.williams@xxxxxxxxx; linuxppc-dev@xxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Li Yang-R58472
> Cc: Shi Xuelin-B29237
> Subject: [PATCH] dmaengine: async_xor, fix zero address issue when xor highmem page
>
> From: Forrest shi <b29237@xxxxxxxxxxxxx>
>
> Â Â Â Âwe may do_sync_xor high mem pages, in this case, page_address will
> Â Â Â Âreturn zero address which cause a failure.

In what scenarios do we xor highmem?

In the case of raid we currently always xor on kmalloc'd memory.

>
> Â Â Â Âthis patch uses kmap_atomic before xor the pages and kunmap_atomic
> Â Â Â Âafter it.
>
> Â Â Â ÂSigned-off-by: b29237@xxxxxxxxxxxxx <xuelin.shi@xxxxxxxxxxxxx>
> ---
> Âcrypto/async_tx/async_xor.c | Â 16 ++++++++++++----
> Â1 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c index bc28337..5b416d1 100644
> --- a/crypto/async_tx/async_xor.c
> +++ b/crypto/async_tx/async_xor.c
> @@ -26,6 +26,7 @@
> Â#include <linux/kernel.h>
> Â#include <linux/interrupt.h>
> Â#include <linux/mm.h>
> +#include <linux/highmem.h>
> Â#include <linux/dma-mapping.h>
> Â#include <linux/raid/xor.h>
> Â#include <linux/async_tx.h>
> @@ -126,7 +127,7 @@ do_sync_xor(struct page *dest, struct page **src_list, unsigned int offset,
> Â Â Â Â Â Âint src_cnt, size_t len, struct async_submit_ctl *submit) Â{
> Â Â Â Âint i;
> - Â Â Â int xor_src_cnt = 0;
> + Â Â Â int xor_src_cnt = 0, kmap_cnt=0;
> Â Â Â Âint src_off = 0;
> Â Â Â Âvoid *dest_buf;
> Â Â Â Âvoid **srcs;
> @@ -138,11 +139,13 @@ do_sync_xor(struct page *dest, struct page **src_list, unsigned int offset,
>
> Â Â Â Â/* convert to buffer pointers */
> Â Â Â Âfor (i = 0; i < src_cnt; i++)
> - Â Â Â Â Â Â Â if (src_list[i])
> - Â Â Â Â Â Â Â Â Â Â Â srcs[xor_src_cnt++] = page_address(src_list[i]) + offset;
> + Â Â Â Â Â Â Â if (src_list[i]) {
> + Â Â Â Â Â Â Â Â Â Â Â srcs[xor_src_cnt++] = kmap_atomic(src_list[i], KM_USER1) + offset;
> + Â Â Â Â Â Â Â }
> + Â Â Â kmap_cnt = xor_src_cnt;

I guess this works now that we have stack based kmap_atomic, but on
older kernels you could not simultaneously map that many buffers with
a single kmap slot.  So if you resend, drop the second parameter to
kmap_atomic.

...but unless you have a non md/raid456 use case in mind, or have
patches to convert md/raid to xor straight out of the incoming biovecs
I don't think this patch is needed right?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/