On Mon, Sep 14 2020 at 23:39, Linus Torvalds wrote:
On Mon, Sep 14, 2020 at 11:24 PM Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
But another reason I tried to avoid kmap_atomic() is that it disables
preemption unconditionally, even on 64-bit architectures where HIGHMEM
is irrelevant. So using kmap_atomic() here means that the bulk of
WireGuard packet encryption runs with preemption disabled, essentially
for legacy reasons.
Agreed. We should definitely fix that.
Well, honestly, one big reason for that is debugging.
The *semantics* of the kmap_atomic() is in the name - you can't sleep
in between it and the kunmap_atomic().
On any sane architecture, kmap_atomic() ends up being a no-op from an
implementation standpoint, and sleeping would work just fine.
But we very much want to make sure that people don't then write code
that doesn't work on the bad old 32-bit machines where it really needs
that sequence to be safe from preemption.
Alternatively we just make highmem a bit more expensive by making these
maps preemptible. RT is doing this for a long time and it's not that
horrible.
The approach is to keep track about the number of active maps in a task
and on an eventual context switch save them away in the task struct and
restore them when the task is scheduled back in.
Thanks,
tglx
