@@ -100,11 +100,15 @@ static inline void scatterwalk_get_sglist(struct scatter_walk *walk,
static inline void scatterwalk_map(struct scatter_walk *walk)
{
struct page *base_page = sg_page(walk->sg);
+ unsigned int offset = walk->offset;
+ void *addr;
if (IS_ENABLED(CONFIG_HIGHMEM)) {
- walk->__addr = kmap_local_page(base_page +
- (walk->offset >> PAGE_SHIFT)) +
- offset_in_page(walk->offset);
+ struct page *page;
+
+ page = nth_page(base_page, offset >> PAGE_SHIFT);
+ offset = offset_in_page(offset);
+ addr = kmap_local_page(page) + offset;
} else {
/*
* When !HIGHMEM we allow the walker to return segments that
@@ -112,13 +116,14 @@ static inline void scatterwalk_map(struct scatter_walk *walk)
* clear that in this case we're working in the linear buffer of
* the whole sg entry in the kernel's direct map rather than
* within the mapped buffer of a single page, compute the
- * address as an offset from the page_address() of the first
- * page of the sg entry. Either way the result is the address
- * in the direct map, but this makes it clearer what is really
- * going on.
+ * address as an offset from the lowmem_page_address() of
+ * the first page of the sg entry. Either way the result
+ * is the address in the direct map, but this makes it clearer
+ * what is really going on.
*/
- walk->__addr = page_address(base_page) + walk->offset;
+ addr = lowmem_page_address(base_page) + offset;
}
+ walk->__addr = addr;
}
/**
Curiously, the Crypto API scatterwalk incremented pages by hand rather than using nth_page. Possibly because scatterwalk predates nth_page (the following commit is from the history tree): commit 3957f2b34960d85b63e814262a8be7d5ad91444d Author: James Morris <jmorris@intercode.com.au> Date: Sun Feb 2 07:35:32 2003 -0800 [CRYPTO]: in/out scatterlist support for ciphers. Fix this by using nth_page. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> --- include/crypto/scatterwalk.h | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-)