[lkml]   [2005]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 01/04] Adding cipher mode context information to crypto_tfm
    On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
    > Fruhwirth Clemens <> 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 <>
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-03-22 14:10    [W:0.033 / U:3.816 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site