Received: by 10.213.65.68 with SMTP id h4csp511343imn; Fri, 16 Mar 2018 10:00:10 -0700 (PDT) X-Google-Smtp-Source: AG47ELtxcusQCZA/nkoNEndTxwFB80C0Pr3HBWJkcc8y0/Am8ba+nr/adb8NIjVqKh0xsWbzRl4J X-Received: by 2002:a17:902:6b4c:: with SMTP id g12-v6mr2829605plt.363.1521219610652; Fri, 16 Mar 2018 10:00:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521219610; cv=none; d=google.com; s=arc-20160816; b=LBR2GKoyu7+zrwgdoG7OZkyQQdhZYsdfl0bW0yQmmVrdrPHvylRyZK4ma9OhrscWo9 +F4xS3TeP/l0GSLxv4VfkqN68DAlfT9PInCwLLon9b7pNB7rZAjjLRAi0su/IV2tpWAY gkduOzsgE+TTj8XXkN8XqwwpHXS5wfnOiCDASe13QZSxvrcWSXYPmP+VJyyGFZa4Uq/B 5yQE29ps0k+FYt7AnsPAsw/TbnRYSuG0N8iJgdJ1E/uM6PJfDdYM/TmhzYN56Csfe5Pd 1d87XK8ipDcAffQoW10sVBqTyByKGkLJFtlgkeKr1cEJLVbA0R3MAvvEB7VI6atrLmwd RlIA== 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:dkim-signature :arc-authentication-results; bh=ZLQMOXCUOqc2JHskPEspIFtAmuXlYR2JsFUjAWQYmek=; b=GfSUlMRTj/fCSMvNWsUNNMmB9SY9BArHO54Mr6rs/EIUfl0vspu/fUSV2cUeY8vICE dKk9pYmirTXfsa9Qv6mmxWoGJwxmpArx4f/YtEPlwtsP7bP10ccjtgwoYt1C00QIX2vL P1Lt/pQzuLnVBP1oOzp7RgBD4aIJ08mCijS1+hPkoGxd/WBWF7m8su505ni4zDLJQxml JmF0t1eQzMgWVBqJ/jqKlk8BWpT27/ECEX76RFaePRK8skoCtrDVcFRGZo7UFKssBqMA QX++j38mR3Ba2gXTF1vo9PHoNAf3rtRm81oXV1tcjACtiy7ibfCFzznAz8e+pvW1IXF/ ecsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=LAB9h6Cw; dkim=fail header.i=@linux-foundation.org header.s=google header.b=budfAtcM; 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 q90si4699242pfi.163.2018.03.16.09.59.55; Fri, 16 Mar 2018 10:00:10 -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=LAB9h6Cw; dkim=fail header.i=@linux-foundation.org header.s=google header.b=budfAtcM; 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 S933113AbeCPQ6u (ORCPT + 99 others); Fri, 16 Mar 2018 12:58:50 -0400 Received: from mail-it0-f44.google.com ([209.85.214.44]:54287 "EHLO mail-it0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753558AbeCPQ6r (ORCPT ); Fri, 16 Mar 2018 12:58:47 -0400 Received: by mail-it0-f44.google.com with SMTP id w3-v6so2881866itc.4 for ; Fri, 16 Mar 2018 09:58:47 -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=ZLQMOXCUOqc2JHskPEspIFtAmuXlYR2JsFUjAWQYmek=; b=LAB9h6CwPbS4Xi5dDYe0iM/Bw8E07RvcC110p2som6ORhTZxP09Yjx8ochP1g7VyWi XZmWroo99eKrcLTprPhqsKQTrctvtqMUVFITCjrjkjMYpnjr3pdUQEhyP+LZMdlhjzOO k8dgAmWXpEpy6KeB+jLX7I1RfOaQED6FWyUWc+Y18Y5HdwVtgmPH2LikPuaqbLao2JWP BHxjJ77GydiTm01RDAaYOmuchhTfilMRbWW2PgeAptuUcDj3cpxcrkQnk4aIltYYqoz+ 2s1rg8CaTrul0901DpLFhUvECP0dlhTYHKbJMXDq/Zm+sJmRRbEiR97SdR0cEQG6blFy +ITQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZLQMOXCUOqc2JHskPEspIFtAmuXlYR2JsFUjAWQYmek=; b=budfAtcMzJGKdRUymRKXSQjt9pwHiyRzWQMTv1H7P/bvSjW0fDb+UarXsI/Vc3213v wpYoGKEZkKZarDi2p3mbs4ghxHz8OkqBYZNseA0atUwEGZTi7BK86YZbGwO/Nbd7GJG4 weNwjF1bIcDWTkcjhZgRh5vpFiEQCkOYc8P80= 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=ZLQMOXCUOqc2JHskPEspIFtAmuXlYR2JsFUjAWQYmek=; b=YtQ9/Z0aP+U519GJkp4fw4BvgVGAzxrj32TZf/snGVKr38ndy5Q41otG3kiSoPXZYG JpuYsLzeAU6K1FkNr0bXT+//GrYkj58P2AHhtnMykXaxzEFZzyC35Cza+HRhHGWsqBqx COBZ1dEnZy+lZ8vwv0jY7DCK7wP5MReOizL1eHM8Xvl/oaaKgWWLHRA+Jv7+MnsSQ2Kf 5WpSDD8LIu5eKbEMF58O50rN8cHz5OXKjVcpQdlOWGGfTxgDv3KqTlCmiYny1c1n99pD e7MhuA4nA8/a2SV205aAWJsAz8sF/SncBsK0gtynKZDbZzxtfhjefsT8ZfWXHT2VLTXl Yhgg== X-Gm-Message-State: AElRT7HwE2UarpCbV/2TVRGERWgl9EXCTwiiYl1i9v7PFCF7y31p6n83 1oz+xH0y/hSGaYiSoK6NAle5GCoDfeGvV4mEIuKYNw== X-Received: by 2002:a24:5989:: with SMTP id p131-v6mr2918155itb.113.1521219527186; Fri, 16 Mar 2018 09:58:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.135.221 with HTTP; Fri, 16 Mar 2018 09:58:46 -0700 (PDT) In-Reply-To: References: <20180315190529.20943-1-linux@dominikbrodowski.net> <20180315190529.20943-15-linux@dominikbrodowski.net> From: Linus Torvalds Date: Fri, 16 Mar 2018 09:58:46 -0700 X-Google-Sender-Auth: glzYhWKosXtNakKBF5BTjdtUJvo Message-ID: Subject: Re: [PATCH v2 14/36] fs: add ksys_mount() helper; remove in-kernel calls to sys_mount() To: Arnd Bergmann Cc: Dominik Brodowski , Linux Kernel Mailing List , 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 1:11 PM, Arnd Bergmann wrote: > > Shouldn't the callers of sys_mount just call do_mount() instead? So for most of these, I'd rather not really change the code and just do a direct translation, but I have to agree that "sys_mount -> do_mount" might be special. As you say, the only thing sys_mount() does is to copy things from user space and allocate temporaries, and then call do_mount(). And we already use do_mount in other places. So it translating sys_mount() to do_mount() might just be the right thing to do. Of course, do_mount() still ends up doing yet more "translate user mode stuff to kernel stuff", so it's kind o fa confusing half-way state where the user mountpoint name is still in user space, and the flags are still in the MS namespace, but the device name and the mount options have been moved to kernel space. So I dunno. It might make sense to convert to do_mount(), but in many ways ksys_mount() that just passes *everything* as if it was a user call is actually more logical, even if it's just pointless churn to then copy things. I do like the mindless "let's just use the SYSCALL_DEFINEx() interfaces for in-kernel use" model, exactly because it's so black-and-white and doesn't have these kinds of "on one hand.." issues. Linus