Re: [PATCH V8 41/44] kmap: Ensure kmap works for devmap pages

[Ira Weiny]

On Tue, Mar 01, 2022 at 12:05:27PM -0800, Dan Williams wrote:
> On Tue, Mar 1, 2022 at 11:45 AM Ira Weiny <ira.weiny@xxxxxxxxx> wrote:
> >
> > On Fri, Feb 04, 2022 at 01:07:10PM -0800, Dan Williams wrote:
> > > On Thu, Jan 27, 2022 at 9:55 AM <ira.weiny@xxxxxxxxx> wrote:
> > > >
> > > > From: Ira Weiny <ira.weiny@xxxxxxxxx>
> > > >
> > > > Users of devmap pages should not have to know that the pages they are
> > > > operating on are special.
> > >
> > > How about get straight to the point without any ambiguous references:
> > >
> > > Today, kmap_{local_page,atomic} handles granting access to HIGHMEM
> > > pages without the caller needing to know if the page is HIGHMEM, or
> > > not. Use that existing infrastructure to grant access to PKS/PGMAP
> > > access protected pages.
> >
> > This sounds better.  Thanks.
> >
> > >
> > > > Co-opt the kmap_{local_page,atomic}() to mediate access to PKS protected
> > > > pages via the devmap facility.  kmap_{local_page,atomic}() are both
> > > > thread local mappings so they work well with the thread specific
> > > > protections available.
> > > >
> > > > kmap(), on the other hand, allows for global mappings to be established,
> > > > Which is incompatible with the underlying PKS facility.
> > >
> > > Why is kmap incompatible with PKS? I know why, but this is a claim
> > > without evidence. If you documented that in a previous patch, there's
> > > no harm and copying and pasting into this one. A future git log user
> > > will thank you for not making them go to lore to try to find the one
> > > patch with the  details.
> >
> > Good point.
> >
> > > Extra credit for creating a PKS theory of
> > > operation document with this detail, unless I missed that?
> >
> > Well...  I've documented and mentioned the thread-local'ness of PKS a lot but
> > I'm pretty close to all of this so it is hard for me to remember where and to
> > what degree that is documented.  I've already reworked the PKS documentation a
> > bit.  So I'll review that.
> >
> > >
> > > > For this reason
> > > > kmap() is not supported.  Rather than leave the kmap mappings to fault
> > > > at random times when users may access them,
> > >
> > > Is that a problem?
> >
> > No.
> 
> What I meant was how random is random and is it distinguishable from
> direct page_address() usage where there is no explicit early failure
> path?

Ok you've convinced me.  I'll drop this.

> 
> >
> > > This instrumentation is also insufficient for
> > > legitimate usages of page_address().
> >
> > True.  Although with this protection those access' are no longer legitimate.
> > And it sounds like it may be worth putting a call in page_address() as well.
> >
> > > Might as well rely on the kernel
> > > developer community being able to debug PKS WARN() splats back to the
> > > source because that will need to be done regardless, given kmap() is
> > > not the only source of false positive access violations.
> >
> > I disagree but I'm happy to drop pgmap_protection_flag_invalid() if that is the
> > consensus.
> >
> > The reason I disagree is that it is generally better to catch errors early
> > rather than later.  Furthermore, this does not change the permissions.  Which
> > means the actual invalid access will also get flagged at the point of use.
> > This allows more debugging information for the user.
> >
> > Do you feel that strongly about removing pgmap_protection_flag_invalid()?
> 
> You haven't convinced me that it matters yet. Do you have an example
> of a kmap() pointer dereference PKS splat where it's not clear from
> the backtrace from the fault handler that a kmap path was involved?
> 
> At a minimum if it stays it seems like something that should be
> wrapped by VM_WARN_ON_ONCE_PAGE() like other page relative memory
> debugging extra checks that get disabled by CONFIG_DEBUG_VM, but the
> assertion that "early is better" needs evidence that "later is too
> ambiguous".

I'll drop this.  It is easier to just leave it out.

Ira