Messages in this thread | | | Date | Fri, 31 Oct 2014 10:57:06 +0100 | From | Maxime Ripard <> | Subject | Re: [PATCH v5 4/4] crypto: Add Allwinner Security System crypto accelerator |
| |
On Fri, Oct 31, 2014 at 04:18:03PM +0800, Herbert Xu wrote: > On Fri, Oct 31, 2014 at 09:13:23AM +0100, Maxime Ripard wrote: > > > > I don't understand here. Why would other drivers *not* being affected? > > > > If the scatter list passed by AF_ALG can be in highmem, I guess it's > > the case for every driver out there. Almost every kernel code I've > > seen so far makes the assumption that the memory it has is mapped and > > accessible. > > > > Somehow, it's the driver's fault now, and not the part of kernel that > > actually does the allocation? > > If you are implementing a crypto driver that is meant to handle > requests from the crypto API then yes you need to handle highmem.
Is that documented somewhere?
> As I said if enough drivers are unable to address highmem and > require copying/software fallbacks then we could provide this > through the API and the driver would then only need to declare > its lack of highmem support or use a helper.
On a 3.18-rc2 kernel:
$ git grep kmap -- crypto/ crypto/ahash.c: walk->data = kmap(walk->pg); crypto/ahash.c: walk->data = kmap_atomic(walk->pg); crypto/async_tx/async_memcpy.c: dest_buf = kmap_atomic(dest) + dest_offset; crypto/async_tx/async_memcpy.c: src_buf = kmap_atomic(src) + src_offset; crypto/scatterwalk.c: return kmap_atomic(scatterwalk_page(walk)) + crypto/shash.c: data = kmap_atomic(sg_page(sg)); crypto/shash.c: data = kmap_atomic(sg_page(sg));
None of the drivers are.
Maxime
-- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com [unhandled content-type:application/pgp-signature] | |