Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220127175505.851391-1-ira.weiny@intel.com> <20220127175505.851391-42-ira.weiny@intel.com>
 <CAPcyv4h1Q6H6_VApe3eFhEwe0McqbrFGRmy9rzFSPP0ATsTeTw@mail.gmail.com> <Yh535Zqe/GtuF/Xh@iweiny-desk3>
In-Reply-To: <Yh535Zqe/GtuF/Xh@iweiny-desk3>
From:   Dan Williams <dan.j.williams@intel.com>
Date:   Tue, 1 Mar 2022 12:05:27 -0800
Message-ID: <CAPcyv4g+Cbqk5bev8=SNz-8EwzofER0HrTzUiJ87ygdWSsXAiA@mail.gmail.com>
Subject: Re: [PATCH V8 41/44] kmap: Ensure kmap works for devmap pages
To:     Ira Weiny <ira.weiny@intel.com>
Cc:     Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Fenghua Yu <fenghua.yu@intel.com>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Mar 1, 2022 at 11:45 AM Ira Weiny <ira.weiny@intel.com> 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@intel.com> wrote:
> > >
> > > From: Ira Weiny <ira.weiny@intel.com>
> > >
> > > 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?

>
> > 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".