Messages in this thread | | | From | Dan Williams <> | Date | Tue, 1 Mar 2022 12:05:27 -0800 | Subject | Re: [PATCH V8 41/44] kmap: Ensure kmap works for devmap pages |
| |
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".
| |