On Mon, Sep 19, 2016 at 2:59 PM, Nadav Har'El <[email protected]> wrote:
> In issue #790, Timmons C. Player discovered something dangerous with > on-stack sched::thread objects: The stack may be mmap()ed, so the scheduler > now needs to access an application's mmap()ed memory area. Those accesses > can potentially have all sort of problems (like page faults in the > scheduler, > if it weren't for issue #143), but more concretely: The "lazy TLB flush" > code added in commit 7e38453 means that the scheduler may see old pages > for application-mmap()ed pages, so it cannot work with a sched::thread in > an > mmap()ed area. > > This patch prevents on-stack sched::thread construction by hiding the > constructor, and only allowing a thread to be created through the function > sched::thread::make(...), which creates the object on the heap. > I had a chat about this with Avi. He would prefer a different solution, which I previously considered but thought would be too much work to implement... The idea is that the sched::thread will contain nothing but a pointer to the real thread structure. The user can create the sched::thread object wherever he pleases, but the constructor will allocate the internal thread structure in the way we want (on the heap). We actually already have exactly this sort of indirection in sched::thread, and it is detached_state, which we needed to hold parts of the thread that we needed to survive the thread just a bit, until the RCU quiet period. So basically now we'll move *all* the thread's state into this detached state. The sched::thread destructor will rcu_dispose() the real thread structure rather than delete it immediately, but can call immediately a new method which cleans up part of the thread (like its stack) which we are sure we no longer need. Most of the private "thread" methods will become methods on the new detached state structure (need a new name for it, maybe thread_impl) and scheduler code which currently handles thread pointers - e.g., the scheduler's run queue - will now have pointers directly to this thread_impl - so the new scheme will not hurt scheduling performance, even the opposite (currently a few of the thread's fields need to be indirected through "detached_state" and this will go away). -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
