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
signature.asc
Description: Digital signature
