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

[Khalid Aziz]

On 01/06/2017 02:19 AM, Michal Hocko wrote:
> On Thu 05-01-17 13:30:10, Khalid Aziz wrote:
> [...]
> > It is very tempting to restrict tags to PAGE_SIZE granularity since it makes
> > code noticeably simpler and that is indeed going to be the majority of
> > cases. Sooner or later somebody would want to use multiple tags per page
> > though.
>
> I didn't get to read the patch throughly yet but I am really confused by
> this statement. The api is mprotect based which makes it ineherently
> PAGE_SIZE granular. How do you want to achieve cache line granularity
> with this API?
>
> And I would really vote for simplicity first... Subpage granularity
> sounds way too tricky...

Hi Michal,

ADI can be enabled for subsets of a task's address space. It takes three 
steps to enable ADI completely:

1. Enable the task to use ADI by setting PSTATE.mcde bit. This is the 
master switch for ADI. mprotect() does this in my patch. Granularity for 
this operation is entire address space for the task.

2. Set TTE.mcd bit for each page translation for the pages one wants ADI 
enabled on. mprotect() does this as well in my patch. Granularity for 
this operation is per page.

3. Set version tag for the addresses task wants to enable ADI on using 
"stxa" instruction. This is done entirely in userspace with no 
assistance or intervention needed from the kernel. Granularity for this 
operation is cache line size which is 64 bytes on Sparc M7.

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.

Thanks,
Khalid