[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c8bb3ea2-d060-5cad-1544-ae5ff5f8fd3b@linux.intel.com>
Date: Thu, 18 Oct 2018 11:46:35 -0700
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Jiri Kosina <jikos@...nel.org>,
Tom Lendacky <thomas.lendacky@....com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
David Woodhouse <dwmw@...zon.co.uk>,
Andi Kleen <ak@...ux.intel.com>,
Dave Hansen <dave.hansen@...el.com>,
Casey Schaufler <casey.schaufler@...el.com>,
Asit Mallick <asit.k.mallick@...el.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
Jon Masters <jcm@...hat.com>, linux-kernel@...r.kernel.org,
x86@...nel.org
Subject: Re: [Patch v3 07/13] x86/process Add arch_set_dumpable
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.
One possible solution is to not use STIBP flag for
non-dumpable processes.
We check during context switch whether
get_dumpable(prev) != get_dumpable(next) in addition
to STIBP flag changes to update SPEC_CTRL MSR and IBPB.
We will need to IPI all other CPUs to update
their SPEC_CTRL MSR if they are using the mm
that has dumpable property changes.
Any better suggestions?
Tim
>
> Thanks,
>
> tglx
>
Powered by blists - more mailing lists