Re: [PATCH 10/17] prmem: documentation
From: Andy Lutomirski
Date: Wed Oct 31 2018 - 16:36:54 EST
> 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.