----- On Aug 10, 2016, at 4:01 AM, Andy Lutomirski luto@xxxxxxxxxxxxxx wrote: > On Tue, Aug 9, 2016 at 9:13 AM, Boqun Feng <boqun.feng@xxxxxxxxx> wrote: <snip> > >> However, I'm thinking maybe we can use some tricks to avoid unnecessary >> aborts-on-preemption. >> >> First of all, I notice we haven't make any constraint on what kind of >> memory objects could be "protected" by rseq critical sections yet. And I >> think this is something we should decide before adding this feature into >> kernel. >> >> We can do some optimization if we have some constraints. For example, if >> the memory objects inside the rseq critical sections could only be >> modified by userspace programs, we therefore don't need to abort >> immediately when userspace task -> kernel task context switch. > > True, although trying to do a syscall in an rseq critical section > seems like a bad idea in general. The scenario above does not require the rseq critical section to perform an explicit system call. It can happen from simple timer-driven preemption of user-space. <snip> > > But do we need to protect MAP_SHARED objects? If not, maybe we could > only track context switches between different tasks sharing the same > mm. I have tracing use-cases involving MAP_SHARED objects for rseq: per-cpu buffers. Moreover, if you only track context switch between tasks with the same mm, you run into issues if you have: Process A Thread 1 (rseq) Thread 2 (rseq) Process B Thread 1 Scheduling: A.1 -> B.1 -> A.2 -> B.1 -> A.1 There is no scheduling between threads of the same process here, but the entire chain involves two threads of the same process accessing the same per-cpu data concurrently. Thanks, Mathieu > > --Andy -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
