Received: by 10.213.65.68 with SMTP id h4csp1556587imn; Thu, 29 Mar 2018 06:56:43 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+t4rEMoBi9mS1pUlfuANVg2AMP53Rno++NYnVSB486WIHmkpSBTpa3ZWUtnuxEWS2tZgMx X-Received: by 10.101.92.2 with SMTP id u2mr5736013pgr.317.1522331803650; Thu, 29 Mar 2018 06:56:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522331803; cv=none; d=google.com; s=arc-20160816; b=c3dhv2CtBP2ZdI0Rg1egqV5FWkS0hSXjr7a9YnHRd5Y1nMY6F/ARzXdX3jnNqad4UW sOnz79KalfcMeWRFSHL38kcdcDcwpyiqgi4JxuElsnWov2BJv36wJcobOTJNOqZR15Hi i2ItkYdoGtobbdf9KBs4vVj55GPuc/GXyuU8B1/f8Sbv+8mZRq6T/uHI6iTqzNUVdrio 1ryy2Zds+V65HwetGBlO4p2DOlHkmetZxwj0/6kiC5sBmOg1Aa6x78imilUlCDrP7ZyK RLA0BMq46CJVjn8h9KYsp1cOmXNPqZuQbNbpZCYzh90zzm/lXLeCgd0oauELxiDFhRjq GQ/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:arc-authentication-results; bh=5+ShEgdiB90i71xNkkUKb4HH/K5//3iZQsEANXLuifM=; b=IdkmnfJ2GHpRcZRLxr3zu5cNRCKlWVdb1Zbm61h5gLFd9bKElJgxGFJN4bK1ZTsxTW eEdWIAfzOne8H0CuSEiz0PLWVyv6kJMPksaI5V6UkbRzzarBC+9jXbiUd3IU0qUcYoh8 sB4pO6uyfHnv4RamBllMj/fujKNe49ea4slJTDtk5hQyxBJJpopQSWzmYQfHEi3kwtaL 6oYQw6sZXhIKW3fc+llsCAHxoaTRA9p1h5Td81UqnG4YWaB1aPjYEoSmZjZdWLpaGTwr h7kKlnTMQC7gwg1physKgS5R3M7XHx4R+tqodO2Ll6IxHik4Lg9HFEvIHIAaCPAE6fl8 BsBg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y62si4030944pgb.728.2018.03.29.06.56.29; Thu, 29 Mar 2018 06:56:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752839AbeC2NyG (ORCPT + 99 others); Thu, 29 Mar 2018 09:54:06 -0400 Received: from mail.efficios.com ([167.114.142.138]:37302 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752314AbeC2NyE (ORCPT ); Thu, 29 Mar 2018 09:54:04 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 07BB71A9F10; Thu, 29 Mar 2018 09:54:03 -0400 (EDT) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail02.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 52rKB0G_UYeG; Thu, 29 Mar 2018 09:54:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id D9B401A9F04; Thu, 29 Mar 2018 09:54:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail02.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id c4Fcvq1tI2kL; Thu, 29 Mar 2018 09:54:01 -0400 (EDT) Received: from mail02.efficios.com (mail02.efficios.com [167.114.142.138]) by mail.efficios.com (Postfix) with ESMTP id BAEE41A9EF8; Thu, 29 Mar 2018 09:54:01 -0400 (EDT) Date: Thu, 29 Mar 2018 09:54:01 -0400 (EDT) From: Mathieu Desnoyers To: Thomas Gleixner Cc: Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Andy Lutomirski , Dave Watson , linux-kernel , linux-api , Paul Turner , Andrew Morton , Russell King , Ingo Molnar , "H. Peter Anvin" , Andrew Hunter , Andi Kleen , Chris Lameter , Ben Maurer , rostedt , Josh Triplett , Linus Torvalds , Catalin Marinas , Will Deacon , Michael Kerrisk , Alexander Viro Message-ID: <87410797.545.1522331641598.JavaMail.zimbra@efficios.com> In-Reply-To: References: <20180327160542.28457-1-mathieu.desnoyers@efficios.com> <20180328145946.GH4082@hirez.programming.kicks-ass.net> <265889560.1.1522250045589.JavaMail.zimbra@efficios.com> <20180328152814.GI4082@hirez.programming.kicks-ass.net> <533214853.56.1522251426819.JavaMail.zimbra@efficios.com> <20180328174935.GK4082@hirez.programming.kicks-ass.net> <181076499.279.1522268382303.JavaMail.zimbra@efficios.com> Subject: Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.142.138] X-Mailer: Zimbra 8.8.7_GA_1964 (ZimbraWebClient - FF52 (Linux)/8.8.7_GA_1964) Thread-Topic: rseq: Introduce restartable sequences system call (v12) Thread-Index: RdfTFUXIFmZrGPQhqX2Rgzxsfz+lIA== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Mar 28, 2018, at 5:25 PM, Thomas Gleixner tglx@linutronix.de wrote: > On Wed, 28 Mar 2018, Mathieu Desnoyers wrote: >> ----- On Mar 28, 2018, at 1:49 PM, Peter Zijlstra peterz@infradead.org wrote: >> > I don't think disallowing system calls is arbitrary. And I think that is >> > something we really want to enforce, because it's batshit insane to >> > allow. >> > >> > And if we allow now, people _will_ use it and we can't ever take it >> > away again. >> >> Here are some examples of how I would like to use system calls within >> rseq critical sections, for testing purposes: >> >> - Issue poll(NULL, 0, ms_timeout) from a rseq critical section, to introduce >> a delay in the critical section and test the effect, > > It's simple enough to use a delay loop for that. It's testing after all. > >> - Issue sched_yield() from a rseq critical section, to introduce preemption at >> that point, > > Make it loop on a varible and use secondary threads to force preemption. > >> - Issue kill() on self, thus testing interruption by signals over rseq c.s., > > Second thread can do that > >> - Invoke sched_setaffinity to tweak the cpu affinity mask to force thread >> migration within a rseq c.s. > > Second thread can do that > >> I currently have only implemented the poll(), sched_yield() and kill() >> test-cases outside of the rseq critical sections, instead relying on >> assembly loops to introduce delays in rseq c.s.. However, if we disallow >> system calls in rseq critical sections, I'll never be able to use those >> systems calls to extend the test matrix. > > All of these tests can be implemented without system calls and there is no > justification to allow system calls just because it makes writing test > cases simpler. Nice try. You bring good points. As a logical consequence, I indeed don't need to issue system calls from rseq c.s. for testing. > >> I see other use-cases where having a system call in a rseq critical section >> could make sense: if vDSO data shared between kernel and user-space rely >> on rseq for synchronization, but a fallback sometimes needs to issue a system >> call for part of the operation. > > What in the VDSO relies on rseqs? Nothing AFAICT. If the VDSO ever goes to > use that then it's going to be a kernel/vdso specific variant and we'll > figure out how that needs to be handled if at all. Sure, and we can craft the vDSO so the system call does not need to be issued within a rseq c.s.. So this one is a non-issue I think. > > But we are not misdesigning now to accomodate artificial scenarios dreamed > up for argumentation sake, If we decide to impose limitations on the rseq c.s. abilities, we need to think this through very carefully. Let's say we disallow system calls from rseq critical sections. A few points arise: - We still need to allow traps (page faults, breakpoints, ...) within rseq c.s., - We still need to allow interrupts within rseq c.s., - We need to decide whether we just document that syscalls within rseq c.s. are not supported, or we enforce a behavior if this happens (e.g. SIGSEGV). If we enforce a SIGSEGV, we'd have to figure out whether it's worth it to add extra branches to the system call fast path to validate this. - If we document that syscalls are not supported within rseq c.s., we should specify whether doing so terminates the process, or if it merely does not guarantee proper abort behavior of the critical section. - We need to carefully consider the case of system calls issued within signal handlers nested on top of rseq. When RSEQ_CS_FLAG_NO_RESTART_ON_SIGNAL is _not_ set, neither in the rseq c.s. descriptor nor in the TLS @flags, it's pretty much straightforward: upon signal delivery, the kernel moves the ip to abort, and clears the tls @rseq_cs pointer. This means that any system call issued within the signal handler is not actually within the rseq c.s. upon which the signal is nested. The case I worry about is if a thread sets the RSEQ_CS_FLAG_NO_RESTART_ON_SIGNAL flag in its TLS @flags field (useful in a debugging scenario where we want a debugger to single-step through the rseq c.s. and observe registers at each step). Arguably, this is only ever used in development. However, it does allow a situation where a system call executed within a signal handler can nest over a rseq c.s.. So if we choose to be very strict and SIGSEGV any syscall nested over rseq c.s., we may very well end up killing the process for no good reason in this scenario. - We need to decide whether all syscalls are disallowed, or if we want to pick specific ones (e.g. fork()). Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com