linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Paul Mackerras <paulus@samba.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Kees Cook <keescook@chromium.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Erik Bosman <ebn310@few.vu.nl>
Subject: Re: Removing per-task TSD? (Re: Tightening up rdpmc permissions?)
Date: Fri, 3 Oct 2014 22:06:24 +0200	[thread overview]
Message-ID: <20141003200624.GL10583@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <CALCETrUwXk-WtfwMRtcg4NO5i8-36HXDqL3BdV7xRWDWT2w7Jw@mail.gmail.com>

On Fri, Oct 03, 2014 at 09:41:30AM -0700, Andy Lutomirski wrote:
> So this is a mess.  I think that any reasonable implementation of
> rdpmc permissions should be per mm, since we perf_event maps are, of
> course, per mm.
> 
> Similarly, any reasonable implementation of rdtsc permissions should
> be per mm, since doing it sensibly involves telling the vdso not to
> use rdtsc, and the vdso is per mm

So far so good.

> Unfortunately, PR_SET_TSC is a per-thread setting.  Implementing this
> correctly looks like it'll require twiddling, or at least thinking
> about, cr4 at switch_mm time *and* when switching tasks, because the
> only sensible way of granting PMC access to a running mm is to
> broadcast a function call to the cpus running that mm.

Confused... now though.

Any cpu can only ever run one mm at the time, and the only way to change
mm on any one cpu is switch_mm(), so having a CR4 write in switch_mm()
will DTRT, no weird broadcasts or anything else required.

Or were you talking about doing the per mm filter while maintaining the
old TIF_NOTSC thing? Then still no broadcasts would be required I think.

> Nonetheless, this is doable.  Either there can be separate context
> switching of CR4.PCE (in switch_mm) and CR4.TSD (in switch_to), or
> there can be some crazy optimization to make it faster.

IFF you want to retain TIF_NOTSC then yes, we'll need both or crazy.

> All of this sucks, so I'll ask a normally verboten question: can we
> just remove PR_SET_TSC entirely?

Fine with me, see more in that thread, I'll try and reply to the right
copy.

  reply	other threads:[~2014-10-03 20:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-03 16:41 Removing per-task TSD? (Re: Tightening up rdpmc permissions?) Andy Lutomirski
2014-10-03 20:06 ` Peter Zijlstra [this message]
2014-10-11 22:32   ` Andy Lutomirski

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=20141003200624.GL10583@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=aarcange@redhat.com \
    --cc=acme@kernel.org \
    --cc=ebn310@few.vu.nl \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).