Messages in this thread | | | Date | Fri, 19 Oct 2018 22:16:36 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [Patch v3 07/13] x86/process Add arch_set_dumpable |
| |
On Fri, 19 Oct 2018, Thomas Gleixner wrote: > On Thu, 18 Oct 2018, Tim Chen wrote: > > On 10/18/2018 06:28 AM, Thomas Gleixner wrote: > > > > > > So now the obvious question. set_dumpable() operates on tsk->mm. i.e. it's > > > a process wide operation. But arch_set_dumpable() operates on the task > > > itself. What about the other tasks of that process? > > > > I missed this part. > > > > Fixing this is tricky as I don't see an easy way to > > reverse map mm back to all tasks that use the same mm > > to update their STIBP flags. > > task is known and handed in to the function. So why do you want to reverse > map mm? > > for_each_thread(task, ...) is what you want. The only thing to verify is > whether you can lock the tasks sighand lock there. And then it's enough to > set/clear the TIF bit and let it take effect at the next context switch.
Though there is another issue with mm shared between processes, i.e. CLONE_VM without CLONE_THREAD where set_dumpabe() affects both processes, but for_each_thread() only seing the threads which belong to the thread group of 'task'.
I can understand your idea of clumping this on dumpable(), but at some point we really have to draw a line and just stop adding more and more expensive stuff to context switch.
Thanks,
tglx
| |