LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Jiri Kosina <jikos@kernel.org>,
Tom Lendacky <thomas.lendacky@amd.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
David Woodhouse <dwmw@amazon.co.uk>,
Andi Kleen <ak@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Casey Schaufler <casey.schaufler@intel.com>,
Asit Mallick <asit.k.mallick@intel.com>,
Arjan van de Ven <arjan@linux.intel.com>,
Jon Masters <jcm@redhat.com>,
linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [Patch v3 07/13] x86/process Add arch_set_dumpable
Date: Mon, 22 Oct 2018 16:55:20 -0700 [thread overview]
Message-ID: <c28c5bc5-fd36-bfba-efd3-7b0e1424db90@linux.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1810192158570.1651@nanos.tec.linutronix.de>
On 10/19/2018 01:16 PM, Thomas Gleixner wrote:
> 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'.
One complication is threads currently running on some remote CPU
when we change flag. Normally we will call spec_ctrl_update_current to make
sure the CPU's current SPEC CTRL MSR stays consistent with TIF flag changes.
But for the remote CPUs, if we don't the update their SPEC CTRL MSRs, their
SPEC CTRL MSR will get out of step with the TIF flag state. It can last for a
long time till we have a TIF flag change during context switches to cause SEPC CTRL MSR
update.
One thing I could do is to add a TIF flag to force update the SPEC_CTRL MSR on
next context switch. Is that okay? Or should I put such flag elsewhere?
Tim
>
> 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
>
next prev parent reply other threads:[~2018-10-22 23:55 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-17 17:59 [Patch v3 00/13] Provide process property based options to enable Spectre v2 userspace-userspace protection Tim Chen
2018-10-17 17:59 ` [Patch v3 01/13] x86/speculation: Clean up spectre_v2_parse_cmdline Tim Chen
2018-10-18 12:43 ` Thomas Gleixner
2018-10-17 17:59 ` [Patch v3 02/13] x86/speculation: Remove unnecessary ret variable in cpu_show_common Tim Chen
2018-10-18 12:46 ` Thomas Gleixner
2018-10-17 17:59 ` [Patch v3 03/13] x86/speculation: Add static key for Enhanced IBRS Tim Chen
2018-10-18 12:50 ` Thomas Gleixner
2018-10-26 16:58 ` Waiman Long
2018-10-26 18:15 ` Tim Chen
2018-10-28 9:32 ` Thomas Gleixner
2018-10-17 17:59 ` [Patch v3 04/13] x86/speculation: Disable STIBP when enhanced IBRS is in use Tim Chen
2018-10-18 12:58 ` Thomas Gleixner
2018-10-26 17:00 ` Waiman Long
2018-10-26 18:18 ` Tim Chen
2018-10-26 18:29 ` Tim Chen
2018-10-17 17:59 ` [Patch v3 05/13] x86/smt: Create cpu_smt_enabled static key for SMT specific code Tim Chen
2018-10-18 13:03 ` Thomas Gleixner
2018-10-19 7:51 ` Peter Zijlstra
2018-10-17 17:59 ` [Patch v3 06/13] mm: Pass task instead of task->mm as argument to set_dumpable Tim Chen
2018-10-18 13:22 ` Thomas Gleixner
2018-10-19 20:02 ` Peter Zijlstra
2018-10-17 17:59 ` [Patch v3 07/13] x86/process Add arch_set_dumpable Tim Chen
2018-10-18 13:28 ` Thomas Gleixner
2018-10-18 18:46 ` Tim Chen
2018-10-19 19:12 ` Thomas Gleixner
2018-10-19 20:16 ` Thomas Gleixner
2018-10-22 23:55 ` Tim Chen [this message]
2018-10-17 17:59 ` [Patch v3 08/13] x86/speculation: Rename SSBD update functions Tim Chen
2018-10-18 13:37 ` Thomas Gleixner
2018-10-17 17:59 ` [Patch v3 09/13] x86/speculation: Reorganize SPEC_CTRL MSR update Tim Chen
2018-10-18 13:47 ` Thomas Gleixner
2018-10-26 17:21 ` Waiman Long
2018-10-26 18:25 ` Tim Chen
2018-10-17 17:59 ` [Patch v3 10/13] x86/speculation: Add per thread STIBP flag Tim Chen
2018-10-18 13:53 ` Thomas Gleixner
2018-10-17 17:59 ` [Patch v3 11/13] x86/speculation: Add Spectre v2 lite app to app protection mode Tim Chen
2018-10-18 15:12 ` Thomas Gleixner
2018-10-17 17:59 ` [Patch v3 12/13] x86/speculation: Protect non-dumpable processes against Spectre v2 attack Tim Chen
2018-10-18 15:17 ` Thomas Gleixner
2018-10-26 17:46 ` Waiman Long
2018-10-26 18:10 ` Tim Chen
2018-10-17 17:59 ` [Patch v3 13/13] x86/speculation: Create PRCTL interface to restrict indirect branch speculation Tim Chen
2018-10-17 19:12 ` Randy Dunlap
2018-10-18 15:31 ` Thomas Gleixner
2018-10-19 7:57 ` [Patch v3 00/13] Provide process property based options to enable Spectre v2 userspace-userspace protection Peter Zijlstra
2018-10-19 16:43 ` Tim Chen
2018-10-19 18:38 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c28c5bc5-fd36-bfba-efd3-7b0e1424db90@linux.intel.com \
--to=tim.c.chen@linux.intel.com \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=arjan@linux.intel.com \
--cc=asit.k.mallick@intel.com \
--cc=casey.schaufler@intel.com \
--cc=dave.hansen@intel.com \
--cc=dwmw@amazon.co.uk \
--cc=jcm@redhat.com \
--cc=jikos@kernel.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--subject='Re: [Patch v3 07/13] x86/process Add arch_set_dumpable' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).