Received: by 10.213.65.68 with SMTP id h4csp198095imn; Thu, 15 Mar 2018 14:03:37 -0700 (PDT) X-Google-Smtp-Source: AG47ELuUbRhz2Ybtv9w+nOVCcntUwU1UhcpBAL1iRGKfpHX2tOz0dFSEnYxEIHlzuN4m4Xiz3T+E X-Received: by 2002:a17:902:aa03:: with SMTP id be3-v6mr9361056plb.211.1521147817131; Thu, 15 Mar 2018 14:03:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521147817; cv=none; d=google.com; s=arc-20160816; b=kVtqVFIY8Jb27v0Q0kBKnJ1WsCL3PvKyYskJP0d/a7MRkxl0JjNTsjFtfa2H6DHDaF hTGeoWMrL8SC2cqDZzodao0kj2/m1U0gDXjgx10c4pwJKNREkijmETlhZGH+AW3r8MkO qXsiFutUZPuaJCnyRc6A1/OXumOlMdm/7WpvXeJ6iOXP2hN06M0Z12a6UhR0YFTkep7N kjvs8lCBl7rNZW/BrVuCfGJBLmSSc5m6vl/4Qjp5GUBdKtkiMdlLlSLpJuCbXWZpSOAE FUMt249CKU1bPSBIh07fzA8iI5pk6Npb8B4OzOnOS9I6ZPlTDzYJA85SU5qbGMc7ozZh Kkiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=xYqGUyb0+niOAF+0P/QzZZE9jfrl0t1D9r00A5DfUxo=; b=TA6hNBvWX18CC8oBN+okiSoIk0cx/xV7rl1z4e8b3H168eEmyktQJBW0VcWveZMhCD tTVSaC11nSd3+9wluVhotI71AJTd6/DnJRiARmA3c28xdmuhPLh770BNkARu25lQgoWh rzD97kLZLddhwEY0zmzXixyragWyPWhWocdNLgbaBZ43kd9580XEGzs58rv+Mpc2fl5i TNHzrJEgfS+PlI25gPg6wZ+5q5v6uK4JxhnFbBxecCVQyz6yxF65Pd95W1CKDGmnKPMZ EBazNj2vKilRBA32II8lJPgS8KzWjUGQtyr7Ur5SK/BNZ8420spTlXJ+XB/FZNOqVUe4 QuKg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Etkf1PpP; 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 m1si4081470pff.43.2018.03.15.14.03.21; Thu, 15 Mar 2018 14:03:37 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Etkf1PpP; 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 S1752658AbeCOVCH (ORCPT + 99 others); Thu, 15 Mar 2018 17:02:07 -0400 Received: from mail-qk0-f193.google.com ([209.85.220.193]:34240 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752457AbeCOVCG (ORCPT ); Thu, 15 Mar 2018 17:02:06 -0400 Received: by mail-qk0-f193.google.com with SMTP id z184so8918598qkc.1 for ; Thu, 15 Mar 2018 14:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=xYqGUyb0+niOAF+0P/QzZZE9jfrl0t1D9r00A5DfUxo=; b=Etkf1PpPwu52+k4JzYw+8pflYx059WFStt7zoRIpxPZ67njBNG1sqRAdh8vJExz4s1 bJ8Kl98K/ghHCMxRMSWMQFADVIZcuVt3U/cslExpoS9qBFauLvGsTo5/u3rdU9JxwvW7 FSY+/1iVhZb1T2harIDMHlx6ghJiYQq6WXzmO7vfIvkG4JtqGENuuKx9tnSDBsQERKZp yEq4+TNFzxAKuSqvYd/MtvkfxkD8IRmAqIMh7XtXfvICqgPFSGmap/IVcTViEyCz+OdC KW4wAyBYQJS2+rIA/ArRw3nX/P4hEw86lsbyV5tyXPCUARUbrHDuYdQ2o6hBOb7EppNC JxCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=xYqGUyb0+niOAF+0P/QzZZE9jfrl0t1D9r00A5DfUxo=; b=hQJaxdYOGaIees1XpdK+XTbu/rHco0lYJNu4Jym+aCHfAkYLx370sgJToe0i6rHAa4 is8BWeerkhkW37jXkPz/Bg+9qx7N6wbz6WYx33c9IutQl6F/zJ3Y5dUDuVXaUR4U0s+k Hl/783KLZ7m3u/sSzBGnL6/T+Kq5kmr8ubu9ahScFKXdRhhNAE7pC9Zrgj8giNhy3RVw aBQu8bOhNrV4XXCdM/bx+efOMB7qCiPKL6WVBdIEw8dK7jm81WyfCpnQxOBBUc4zR4gV es762FrUwscFS8S6O8AztGip4Vr+QuW4sGJPqU3XvJU/FaX5nWstmKQu4Wg0Z6A8k2Ew 4+ZQ== X-Gm-Message-State: AElRT7Ehonpe/Lpf/woV5B3PJClNgGbA/lEcQIwls9fVeBwWZIMgPnxq yQhtwby6w4rVkHw8ano4k/f+Tb7XDOaNeP+0q34= X-Received: by 10.55.9.146 with SMTP id 140mr14088390qkj.343.1521147725608; Thu, 15 Mar 2018 14:02:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.185.46 with HTTP; Thu, 15 Mar 2018 14:02:04 -0700 (PDT) In-Reply-To: <20180315190529.20943-1-linux@dominikbrodowski.net> References: <20180315190529.20943-1-linux@dominikbrodowski.net> From: Arnd Bergmann Date: Thu, 15 Mar 2018 22:02:04 +0100 X-Google-Sender-Auth: hXd0YqxNgnUZh1JLEtstgT_D9cc Message-ID: Subject: Re: [PATCH v2 00/36] remove in-kernel syscall invocations (part 1) To: Dominik Brodowski Cc: Linux Kernel Mailing List , Linus Torvalds , Al Viro , Andy Lutomirski , Ingo Molnar , Andrew Morton Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 15, 2018 at 8:04 PM, Dominik Brodowski wrote: > Here is a re-spin of the first set of patches which reduce the number of > syscall invocations from within the kernel; the RFC may be found at > > The rationale for this change is described in patch 1 as follows: > > The syscall entry points to the kernel defined by SYSCALL_DEFINEx() > and COMPAT_SYSCALL_DEFINEx() should only be called from userspace > through kernel entry points, but not from the kernel itself. This > will allow cleanups and optimizations to the entry paths *and* to > the parts of the kernel code which currently need to pretend to be > userspace in order to make use of syscalls. > > The whole series can be found at > > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git syscalls-next > > and will be submitted for merging for the v4.17-rc1 cycle, probably together > with another batch of related patches I hope to send out tomorrow as a RFC. Nice work! I've already commented on a few patches that now have a kernel-internal helper function that takes a __user pointer. I think those are all only used in the early boot code (initramfs etc) that runs before we set_fs() to the user address space, but it also causes warnings with sparse. If we can change all of them to take kernel pointers, that would let us avoid the sparse warnings and start running with a normal user address space view. Unfortunately, some of the syscall seem to be harder to change to that than others, so not sure if it's worth the effort. Another open question are the declarations in include/linux/syscalls.h. These serve as a help for type-checking today, making sure that each syscall we refer to from either the syscall table or called by some kernel function uses the same prototype that matches the syscall definition, which raises the question of whether we want to keep the header around at all. Arnd