[PATCH RFC PKS/PMEM 05/58] kmap: Introduce k[un]map_thread
ira.weiny at intel.com
Mon Nov 9 23:59:54 EST 2020
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny <ira.weiny at intel.com>
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required to set the protections on multiple
> > processors (globally). Enabling PKS globally can be very expensive
> > depending on the requested operation. Furthermore, enabling a domain
> > globally reduces the protection afforded by PKS.
> > Most kmap() (Aprox 209 of 229) callers use the map within a single thread and
> > have no need for the protection domain to be enabled globally. However, the
> > remaining callers do not follow this pattern and, as best I can tell, expect
> > the mapping to be 'global' and available to any thread who may access the
> > mapping.
> > We don't anticipate global mappings to pmem, however in general there is a
> > danger in changing the semantics of kmap(). Effectively, this would cause an
> > unresolved page fault with little to no information about why the failure
> > occurred.
> > To resolve this a number of options were considered.
> > 1) Attempt to change all the thread local kmap() calls to kmap_atomic()
> > 2) Introduce a flags parameter to kmap() to indicate if the mapping should be
> > global or not
> > 3) Change ~20 call sites to 'kmap_global()' to indicate that they require a
> > global enablement of the pages.
> > 4) Change ~209 call sites to 'kmap_thread()' to indicate that the mapping is to
> > be used within that thread of execution only
> > Option 1 is simply not feasible. Option 2 would require all of the call sites
> > of kmap() to change. Option 3 seems like a good minimal change but there is a
> > danger that new code may miss the semantic change of kmap() and not get the
> > behavior the developer intended. Therefore, #4 was chosen.
> There is Option #5:
There is now yes. :-D
> Convert the thread local kmap() invocations to the proposed kmap_local()
> interface which is coming along .
I've been trying to follow that thread.
> That solves a couple of issues:
> 1) It relieves the current kmap_atomic() usage sites from the implict
> pagefault/preempt disable semantics which apply even when
> CONFIG_HIGHMEM is disabled. kmap_local() still can be invoked from
> atomic context.
> 2) Due to #1 it allows to replace the conditional usage of kmap() and
> kmap_atomic() for purely thread local mappings.
> 3) It puts the burden on the HIGHMEM inflicted systems
> 4) It is actually more efficient for most of the pure thread local use
> cases on HIGHMEM inflicted systems because it avoids the overhead of
> the global lock and the potential kmap slot exhaustion. A potential
> preemption will be more expensive, but that's not really the case we
> want to optimize for.
> 5) It solves the RT issue vs. kmap_atomic()
> So instead of creating yet another variety of kmap() which is just
> scratching the particular PKRS itch, can we please consolidate all of
> that on the wider reaching kmap_local() approach?
Yes I agree. We absolutely don't want more kmap*() calls and I was hoping to
dovetail into your kmap_local() work.
I've pivoted away from this work a bit to clean up all the
kmap()/memcpy*()/kunmaps() as discussed elsewhere in the thread first. I
was hoping your work would land and then I could s/kmap_thread()/kmap_local()/
on all of these patches.
Also, we can convert the new memcpy_*_page() calls to kmap_local() as well.
[For now my patch just uses kmap_atomic().]
I've not looked at all of the patches in your latest version. Have you
included converting any of the kmap() call sites? I thought you were more
focused on converting the kmap_atomic() to kmap_local()?
>  https://email@example.com/
More information about the kexec