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
