lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 12 Oct 2020 17:44:38 +0100
From:   Matthew Wilcox <>
To:     Dave Hansen <>
Cc:     Eric Biggers <>,
        Ira Weiny <>,
        Andrew Morton <>,
        Thomas Gleixner <>,
        Ingo Molnar <>, Borislav Petkov <>,
        Andy Lutomirski <>,
        Peter Zijlstra <>,,,,,,
        Dave Hansen <>,,,,,,,,,,,,,,,,,,,,,,,
        Fenghua Yu <>,,,,,,,,
        Jaegeuk Kim <>,
        Dan Williams <>,,,,,,,,,,,
Subject: Re: [PATCH RFC PKS/PMEM 22/58] fs/f2fs: Utilize new kmap_thread()

On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote:
> kmap_atomic() is always preferred over kmap()/kmap_thread().
> kmap_atomic() is _much_ more lightweight since its TLB invalidation is
> always CPU-local and never broadcast.
> So, basically, unless you *must* sleep while the mapping is in place,
> kmap_atomic() is preferred.

But kmap_atomic() disables preemption, so the _ideal_ interface would map
it only locally, then on preemption make it global.  I don't even know
if that _can_ be done.  But this email makes it seem like kmap_atomic()
has no downsides.

Powered by blists - more mailing lists