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

Reply via email to