> 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.
