Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

From: Linus Torvalds
Date: Mon Sep 21 2020 - 12:25:14 EST

On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> If a task is migrated to a different CPU then the mapping address will
> change which will explode in colourful ways.


Right you are.

Maybe we really *could* call this new kmap functionality something
like "kmap_percpu()" (or maybe "local" is good enough), and make it
act like your RT code does for spinlocks - not disable preemption, but
only disabling CPU migration.

That would probably be good enough for a lot of users that don't want
to expose excessive latencies, but where it's really not a huge deal
to say "stick to this CPU for a short while".

The crypto code certainly sounds like one such case.