On Tue, Oct 30, 2018 at 11:03:51AM -0700, Dave Hansen wrote: > On 10/30/18 10:58 AM, Matthew Wilcox wrote: > > Does this satisfy Igor's requirements? We wouldn't be able to > > copy_to/from_user() while rare_mm was active. I think that's a feature > > though! It certainly satisfies my interests (kernel code be able to > > mark things as dynamically-allocated-and-read-only-after-initialisation) > > It has to be more than copy_to/from_user(), though, I think. > > rare_modify(q) either has to preempt_disable(), or we need to teach the > context-switching code when and how to switch in/out of the rare_mm. > preempt_disable() would also keep us from sleeping. Yes, I think we want to have preempt disable at the very least. We could indeed make the context switch code smart and teach is about this state, but I think allowing preemption in such section is a bad idea. We want to keep these sections short and simple (and bounded), such that they can be analyzed for correctness. Once you allow preemption, things tend to grow large and complex. Ideally we'd even disabled interrupts over this, to further limit what code runs in the rare_mm context. NMIs need special care anyway.
