Re: [RFC PATCH v3] sparc64: Add support for Application Data Integrity (ADI)

[Khalid Aziz]

On 01/06/2017 09:55 AM, Dave Hansen wrote:
> On 01/06/2017 08:22 AM, Khalid Aziz wrote:
> > On 01/06/2017 08:36 AM, Dave Hansen wrote:
> > > On 01/06/2017 07:32 AM, Khalid Aziz wrote:
> > > > I agree with you on simplicity first. Subpage granularity is complex,
> > > > but the architecture allows for subpage granularity. Maybe the right
> > > > approach is to support this at page granularity first for swappable
> > > > pages and then expand to subpage granularity in a subsequent patch?
> > > > Pages locked in memory can already use subpage granularity with my
> > > > patch.
> > >
> > > What do you mean by "locked in memory"?  mlock()'d memory can still be
> > > migrated around and still requires "swap" ptes, for instance.
> >
> > You are right. Page migration can invalidate subpage granularity even
> > for locked pages. Is it possible to use cpusets to keep a task and its
> > memory locked on a single node?
>
> It's going to be hard to impossible to guarantee.  mlock() doesn't
> guarantee that things won't change physical addresses.  You'd have to
> change that guarantee or chase all the things in the kernel that might
> change physical addresses (compaction, ksm, etc...).
>
> Actually, that reminds me...  How does your code interface with ksm?  Or
> is there no interaction needed since you're always working on virtual
> addresses?

Yes, version tags are interpreted at virtual address level.

--
Khalid