Re: [PATCH 10/17] prmem: documentation

[Andy Lutomirski]

> On Oct 31, 2018, at 3:02 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> 
>> On Tue, Oct 30, 2018 at 09:41:13PM -0700, Andy Lutomirski wrote:
>> To clarify some of this thread, I think that the fact that rare_write
>> uses an mm_struct and alias mappings under the hood should be
>> completely invisible to users of the API.  No one should ever be
>> handed a writable pointer to rare_write memory (except perhaps during
>> bootup or when initializing a large complex data structure that will
>> be rare_write but isn't yet, e.g. the policy db).
> 
> Being able to use pointers would make it far easier to do atomics and
> other things though.

This stuff is called *rare* write for a reason. Do we really want to allow atomics beyond just store-release?  Taking a big lock and then writing in the right order should cover everything, no?

> 
>> For example, there could easily be architectures where having a
>> writable alias is problematic.
> 
> Mostly we'd just have to be careful of cache aliases, alignment should
> be able to sort that I think.
> 
>> If you have multiple pools and one mm_struct per pool, you'll need a
>> way to find the mm_struct from a given allocation.
> 
> Or keep track of it externally. For example by context. If you modify
> page-tables you pick the page-table pool, if you modify selinux state,
> you pick the selinux pool.
> 
>> Regardless of how the mm_structs are set up, changing rare_write
>> memory to normal memory or vice versa will require a global TLB flush
>> (all ASIDs and global pages) on all CPUs, so having extra mm_structs
>> doesn't seem to buy much.
> 
> The way I understand it, the point is that if you stick page-tables and
> selinux state in different pools, a stray write in one will never affect
> the other.
> 

Hmm. Thatâs not totally crazy, but the API would need to be carefully designed. And some argument would have to be made as to why itâs better to use a different address space as opposed to checking in software along the lines of the uaccess checking.