Re: [PATCH 01/04] Adding cipher mode context information to crypto_tfm

[Fruhwirth Clemens <clemens@endorphin.org>]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <clemens@endorphin.org> wrote:
> >
> > It must be
> >  possible to process more than 2 mappings in softirq context.
> 
> Adding a few more fixmap slots wouldn't hurt anyone.  But if you want an
> arbitrarily large number of them then no, we cannot do that.

What magnitude is "few more"? 2, 10, 100?

> Taking more than one sleeping kmap at a time within the same process is
> deadlocky, btw.  You can end up with N such tasks all holding one kmap and
> waiting for someone else to release one.
> 
> Possibly one could arrange for the pages to not be in highmem at all.

Is there an easy way to bring pages to lowmem? The cryptoapi is called
from the backlog of the networking stack, which is assigned in irq
context first and processed softirq context. There is little opportunity
to bringt stuff to low mem. And we can't bringt stuff to lowmem on our
own as well, because (as I guess) this involves a page allocation, which
would have to be GFP_ATOMIC, which can fail. So we would need fallback
for the fallback mechanism, and that's still the tiny set of scratch
buffers.. hairy business..

Ok, what about the following plan:

If context == softirq, use kmap_atomic until they all used, fall-back to
scratch buffers, and printk in some DEBUG mode:"Warning slow, redesign
your client or raise the number of fixmaps".

If context == user, use kmap_atomic until they all used, and fall-back
to kmap.

-- 
Fruhwirth Clemens <clemens@endorphin.org>  http://clemens.endorphin.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]