From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Boqun Feng <boqun.feng@gmail.com>,
Andy Lutomirski <luto@amacapital.net>,
Dave Watson <davejwatson@fb.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-api <linux-api@vger.kernel.org>,
Paul Turner <pjt@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Russell King <linux@arm.linux.org.uk>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Andrew Hunter <ahh@google.com>, Andi Kleen <andi@firstfloor.org>,
Chris Lameter <cl@linux.com>, Ben Maurer <bmaurer@fb.com>,
rostedt <rostedt@goodmis.org>,
Josh Triplett <josh@joshtriplett.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Michael Kerrisk <mtk.manpages@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [RFC PATCH v11 for 4.15 01/24] Restartable sequences system call
Date: Thu, 16 Nov 2017 20:37:58 +0000 (UTC) [thread overview]
Message-ID: <1083699948.16848.1510864678185.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20171116191448.rmds347hwsyibipm@hirez.programming.kicks-ass.net>
----- On Nov 16, 2017, at 2:14 PM, Peter Zijlstra peterz@infradead.org wrote:
> On Tue, Nov 14, 2017 at 03:03:51PM -0500, Mathieu Desnoyers wrote:
>> +static bool rseq_update_cpu_id(struct task_struct *t)
>> +{
>> + uint32_t cpu_id = raw_smp_processor_id();
>> +
>> + if (__put_user(cpu_id, &t->rseq->cpu_id_start))
>> + return false;
>> + if (__put_user(cpu_id, &t->rseq->cpu_id))
>> + return false;
>
> For LP64 this _could_ be a single 64bit store, right? It would save some
> stac/clac noise on x86_64.
Yes it could, but last time I checked a __put_user of a u64
did not guarantee single-copy atomicity of each of the two
32-bit words on 32-bit architectures, so I figured that it
would be better to postpone that optimization to a point
where architectures would provide a u64 __put_user that
guarantee single-copy atomicity of each 32-bit word on 32-bit
architectures.
>
>> + trace_rseq_update(t);
>> + return true;
>> +}
>
>> +static bool rseq_get_rseq_cs(struct task_struct *t,
>
> bool return value, but is used as a C int error value later (it works,
> but is inconsistent).
I can do the following on the caller side instead:
if (!rseq_get_rseq_cs(t, &start_ip, &post_commit_offset, &abort_ip,
&cs_flags))
return -EFAULT;
>
>> + void __user **start_ip,
>> + unsigned long *post_commit_offset,
>> + void __user **abort_ip,
>> + uint32_t *cs_flags)
>
> That's a fair amount of arguments, and I suppose that isn't a problem
> because there's only the one callsite and it all gets inlined anyway.
Yep.
>
>> +{
>> + unsigned long ptr;
>> + struct rseq_cs __user *urseq_cs;
>> + struct rseq_cs rseq_cs;
>> + u32 __user *usig;
>> + u32 sig;
>> +
>> + if (__get_user(ptr, &t->rseq->rseq_cs))
>> + return false;
>> + if (!ptr)
>> + return true;
>> + urseq_cs = (struct rseq_cs __user *)ptr;
>> + if (copy_from_user(&rseq_cs, urseq_cs, sizeof(rseq_cs)))
>> + return false;
>> + /*
>> + * We need to clear rseq_cs upon entry into a signal handler
>> + * nested on top of a rseq assembly block, so the signal handler
>> + * will not be fixed up if itself interrupted by a nested signal
>> + * handler or preempted. We also need to clear rseq_cs if we
>> + * preempt or deliver a signal on top of code outside of the
>> + * rseq assembly block, to ensure that a following preemption or
>> + * signal delivery will not try to perform a fixup needlessly.
>> + */
>> + if (clear_user(&t->rseq->rseq_cs, sizeof(t->rseq->rseq_cs)))
>> + return false;
>> + if (rseq_cs.version > 0)
>> + return false;
>
>> + *cs_flags = rseq_cs.flags;
>> + *start_ip = (void __user *)rseq_cs.start_ip;
>> + *post_commit_offset = (unsigned long)rseq_cs.post_commit_offset;
>> + *abort_ip = (void __user *)rseq_cs.abort_ip;
>
>> + usig = (u32 __user *)(rseq_cs.abort_ip - sizeof(u32));
>> + if (get_user(sig, usig))
>> + return false;
>
ok for adding newlines.
>> + if (current->rseq_sig != sig) {
>> + printk_ratelimited(KERN_WARNING
>> + "Possible attack attempt. Unexpected rseq signature 0x%x, expecting 0x%x
>> (pid=%d, addr=%p).\n",
>> + sig, current->rseq_sig, current->pid, usig);
>> + return false;
>> + }
>> + return true;
>> +}
>> +
>> +static int rseq_need_restart(struct task_struct *t, uint32_t cs_flags)
>> +{
>> + bool need_restart = false;
>> + uint32_t flags;
>> +
>> + /* Get thread flags. */
>> + if (__get_user(flags, &t->rseq->flags))
>> + return -EFAULT;
>> +
>> + /* Take into account critical section flags. */
>> + flags |= cs_flags;
>> +
>> + /*
>> + * Restart on signal can only be inhibited when restart on
>> + * preempt and restart on migrate are inhibited too. Otherwise,
>> + * a preempted signal handler could fail to restart the prior
>> + * execution context on sigreturn.
>> + */
>> + if (flags & RSEQ_CS_FLAG_NO_RESTART_ON_SIGNAL) {
>> + if (!(flags & RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE))
>> + return -EINVAL;
>> + if (!(flags & RSEQ_CS_FLAG_NO_RESTART_ON_PREEMPT))
>> + return -EINVAL;
>> + }
>> + if (t->rseq_migrate
>> + && !(flags & RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE))
>
> That's a horrible code form, please put the && at the end of the
> previous line and begin the next line aligned with the (, like:
>
> if (t->rseq_migrate &&
> !(flags & RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE))
>
> Luckily you've already killed this code, but try and remember for a next
> time ;-)
I usually never space-align with open parenthesis "(". Is it a coding
style requirement of the kernel for multi-line if () conditions ?
Would the following replatement code be ok ?
if (unlikely(flags & RSEQ_CS_FLAG_NO_RESTART_ON_SIGNAL)) {
if ((flags & (RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE
| RSEQ_CS_FLAG_NO_RESTART_ON_PREEMPT)) !=
(RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE
| RSEQ_CS_FLAG_NO_RESTART_ON_PREEMPT))
return -EINVAL;
}
event_mask = t->rseq_event_mask;
t->rseq_event_mask = 0;
event_mask &= ~flags;
if (event_mask)
return 1;
return 0;
I'm uneasy with the wall of text caused by the flags. And based on
your comment, I should align on the if ( parenthesis. Style improvement
ideas are welcome. An alternative would be:
if (unlikely(flags & RSEQ_CS_FLAG_NO_RESTART_ON_SIGNAL)) {
if ((flags & (RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE
| RSEQ_CS_FLAG_NO_RESTART_ON_PREEMPT)) !=
(RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE
| RSEQ_CS_FLAG_NO_RESTART_ON_PREEMPT))
return -EINVAL;
}
[...]
>
>> + need_restart = true;
>> + else if (t->rseq_preempt
>> + && !(flags & RSEQ_CS_FLAG_NO_RESTART_ON_PREEMPT))
>> + need_restart = true;
>> + else if (t->rseq_signal
>> + && !(flags & RSEQ_CS_FLAG_NO_RESTART_ON_SIGNAL))
>> + need_restart = true;
>> +
>> + t->rseq_preempt = false;
>> + t->rseq_signal = false;
>> + t->rseq_migrate = false;
>> + if (need_restart)
>> + return 1;
>> + return 0;
>> +}
>> +
>> +static int rseq_ip_fixup(struct pt_regs *regs)
>> +{
>> + struct task_struct *t = current;
>> + void __user *start_ip = NULL;
>> + unsigned long post_commit_offset = 0;
>> + void __user *abort_ip = NULL;
>> + uint32_t cs_flags = 0;
>> + int ret;
>
> unsigned long ip = instruction_pointer(regs);
ok
>
>> +
>> + ret = rseq_get_rseq_cs(t, &start_ip, &post_commit_offset, &abort_ip,
>> + &cs_flags);
> trace_rseq_ip_fixup((void __user *)ip,
>> + start_ip, post_commit_offset, abort_ip, ret);
>
> Why trace here and not right before/after instruction_pointer_set()?
Good point. Tracing right before instruction_pointer_set() would make sense.
I can remove the "ret" parameter too.
>
>> + if (!ret)
>> + return -EFAULT;
>> +
>> + ret = rseq_need_restart(t, cs_flags);
>> + if (ret < 0)
>> + return -EFAULT;
>> + if (!ret)
>> + return 0;
>> + /*
>> + * Handle potentially not being within a critical section.
>> + * Unsigned comparison will be true when
>> + * ip < start_ip (wrap-around to large values), and when
>> + * ip >= start_ip + post_commit_offset.
>> + */
>> + if ((unsigned long)instruction_pointer(regs) - (unsigned long)start_ip
>> + >= post_commit_offset)
>
> if ((unsigned long)(ip - start_ip) >= post_commit_offset)
Now that both ip and start_ip are unsigned long, I simply can do:
if (ip - start_ip >= post_commit_offset)
...
>
>> + return 1;
>> +
>> + instruction_pointer_set(regs, (unsigned long)abort_ip);
>
> Since you only ever use abort_ip as unsigned long, why propagate this
> "void __user *" all the way from rseq_get_rseq_cs() ? Save yourself some
> typing and casts :-)
Will do, I'll use unsigned long instead,
Thanks!
Mathieu
>
>> + return 1;
> > +}
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2017-11-16 20:37 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-14 20:03 [RFC PATCH for 4.15 00/24] Restartable sequences and CPU op vector v11 Mathieu Desnoyers
2017-11-14 20:03 ` [RFC PATCH v11 for 4.15 01/24] Restartable sequences system call Mathieu Desnoyers
2017-11-14 20:39 ` Ben Maurer
2017-11-14 20:52 ` Mathieu Desnoyers
2017-11-14 21:48 ` Ben Maurer
[not found] ` <CY4PR15MB168884529B3C0F8E6CC06257CF280@CY4PR15MB1688.namprd15.prod.outlook.com>
2017-11-14 20:49 ` Ben Maurer
2017-11-14 21:03 ` Mathieu Desnoyers
2017-11-16 16:18 ` Peter Zijlstra
2017-11-16 16:27 ` Mathieu Desnoyers
2017-11-16 16:32 ` Peter Zijlstra
2017-11-16 17:09 ` Mathieu Desnoyers
2017-11-16 18:43 ` Peter Zijlstra
2017-11-16 18:49 ` Mathieu Desnoyers
2017-11-16 19:06 ` Thomas Gleixner
2017-11-16 20:06 ` Mathieu Desnoyers
2017-11-16 19:14 ` Peter Zijlstra
2017-11-16 20:37 ` Mathieu Desnoyers [this message]
2017-11-16 20:46 ` Peter Zijlstra
2017-11-16 21:08 ` Thomas Gleixner
2017-11-19 17:24 ` Mathieu Desnoyers
2017-11-14 20:03 ` [RFC PATCH for 4.15 02/24] Restartable sequences: ARM 32 architecture support Mathieu Desnoyers
2017-11-14 20:03 ` [RFC PATCH for 4.15 03/24] Restartable sequences: wire up ARM 32 system call Mathieu Desnoyers
2017-11-14 20:03 ` [RFC PATCH for 4.15 04/24] Restartable sequences: x86 32/64 architecture support Mathieu Desnoyers
2017-11-16 21:14 ` Thomas Gleixner
2017-11-19 17:41 ` Mathieu Desnoyers
2017-11-20 8:38 ` Thomas Gleixner
2017-11-14 20:03 ` [RFC PATCH for 4.15 05/24] Restartable sequences: wire up x86 32/64 system call Mathieu Desnoyers
2017-11-14 20:03 ` [RFC PATCH for 4.15 06/24] Restartable sequences: powerpc architecture support Mathieu Desnoyers
2017-11-14 20:03 ` [RFC PATCH for 4.15 07/24] Restartable sequences: Wire up powerpc system call Mathieu Desnoyers
2017-11-14 20:03 ` [RFC PATCH v3 for 4.15 08/24] Provide cpu_opv " Mathieu Desnoyers
2017-11-15 1:34 ` Mathieu Desnoyers
2017-11-15 7:44 ` Michael Kerrisk (man-pages)
2017-11-15 14:30 ` Mathieu Desnoyers
2017-11-16 23:26 ` Thomas Gleixner
2017-11-17 0:14 ` Andi Kleen
2017-11-17 10:09 ` Thomas Gleixner
2017-11-17 17:14 ` Mathieu Desnoyers
2017-11-17 18:18 ` Andi Kleen
2017-11-17 18:59 ` Thomas Gleixner
2017-11-17 19:15 ` Andi Kleen
2017-11-17 20:07 ` Thomas Gleixner
2017-11-18 21:09 ` Andy Lutomirski
2017-11-17 20:22 ` Thomas Gleixner
2017-11-20 17:13 ` Mathieu Desnoyers
2017-11-20 16:13 ` Mathieu Desnoyers
2017-11-20 17:48 ` Thomas Gleixner
2017-11-20 18:03 ` Thomas Gleixner
2017-11-20 18:42 ` Mathieu Desnoyers
2017-11-20 18:39 ` Mathieu Desnoyers
2017-11-20 18:49 ` Andi Kleen
2017-11-20 22:46 ` Mathieu Desnoyers
2017-11-20 19:44 ` Thomas Gleixner
2017-11-21 11:25 ` Mathieu Desnoyers
2017-11-14 20:03 ` [RFC PATCH for 4.15 09/24] cpu_opv: Wire up x86 32/64 " Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH for 4.15 10/24] cpu_opv: Wire up powerpc " Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH for 4.15 11/24] cpu_opv: Wire up ARM32 " Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH v2 for 4.15 12/24] cpu_opv: Implement selftests Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH v2 for 4.15 13/24] Restartable sequences: Provide self-tests Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH for 4.15 14/24] Restartable sequences selftests: arm: workaround gcc asm size guess Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH v2 for 4.15 15/24] membarrier: selftest: Test private expedited cmd Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH v7 for 4.15 16/24] membarrier: powerpc: Skip memory barrier in switch_mm() Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH v5 for 4.15 17/24] membarrier: Document scheduler barrier requirements Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH for 4.15 18/24] membarrier: provide SHARED_EXPEDITED command Mathieu Desnoyers
2017-11-15 1:36 ` Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH for 4.15 19/24] membarrier: selftest: Test shared expedited cmd Mathieu Desnoyers
2017-11-17 15:07 ` Shuah Khan
2017-11-14 20:04 ` [RFC PATCH for 4.15 20/24] membarrier: Provide core serializing command Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH v2 for 4.15 21/24] x86: Introduce sync_core_before_usermode Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH v2 for 4.15 22/24] membarrier: x86: Provide core serializing command Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH for 4.15 23/24] membarrier: selftest: Test private expedited sync core cmd Mathieu Desnoyers
2017-11-17 15:09 ` Shuah Khan
2017-11-17 16:17 ` Mathieu Desnoyers
2017-11-14 20:04 ` [RFC PATCH for 4.15 24/24] membarrier: arm64: Provide core serializing command Mathieu Desnoyers
2017-11-14 21:08 ` [RFC PATCH for 4.15 00/24] Restartable sequences and CPU op vector v11 Linus Torvalds
2017-11-14 21:15 ` Andy Lutomirski
2017-11-14 21:32 ` Paul Turner
2018-03-27 18:15 ` Mathieu Desnoyers
2017-11-14 21:32 ` Mathieu Desnoyers
2017-11-15 4:12 ` Andy Lutomirski
2017-11-15 6:34 ` Mathieu Desnoyers
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=1083699948.16848.1510864678185.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=ahh@google.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=bmaurer@fb.com \
--cc=boqun.feng@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=cl@linux.com \
--cc=davejwatson@fb.com \
--cc=hpa@zytor.com \
--cc=josh@joshtriplett.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=mtk.manpages@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=will.deacon@arm.com \
/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