Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp834237yba; Thu, 16 May 2019 09:35:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqxeR4u1+n034cDul009zLWDD0fVZAz0AI8QCZZavJWyskZd4lJSE4sR+UZQoWBAI6s3TUEU X-Received: by 2002:aa7:998d:: with SMTP id k13mr42397793pfh.217.1558024528854; Thu, 16 May 2019 09:35:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558024528; cv=none; d=google.com; s=arc-20160816; b=FCCL4BE05Ckc079Z5tktZk7kgVnenhw5TPo3fS5KnMOudjhK5TAQxb1X3TCgnkumC4 R77ZACNeJ7swK75z5jmA2EoR9pHni/EcWYOu16WikeAi0n03sUW+pyb0p2Tn1TPamK9s pEASFFstWFF9wxiWI5W9avrjTRuBqXsrhSf2JIntuaUUeLMKKBubi/HQrnvcuQyJGi8E zMbWYvbSy/jJ9U4BTllOlTPe4yOyr8iR3loABAfps768Zb14N0xtvh3G9PS4l4dJPSJe fvoYEj+ywIIYtWFDKOha2kdUWlngiCpXLUru7keh+MO/4FIkCa2abnEQo5DiOJHg+EMq 7Cnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=KqJptEE9UZAQB57XWQVEM7jKvQBAFnzvaSb4s/mzn1A=; b=JMx/YziP2zPZ9Wnvp8ksv6mEh6elarN4PH+AYOD4/Q+K4jJbru5/0lepPSvX3pnO9M syxJd5P9wmTw18NtZCH26f626Fbfn0p8sn7c4ltYF5OK77z0Pyn9rUsOzTB/TdK4CC1A iiuKwFdVEVtQUblhv0iod8DQVJhUGj1723gQ0UdYBgZidxEXS/ebBXvdo/Ys4Ck7T1vZ nDRpA6iGo5R1+9G+4JvUcL82Xy7x4w1NuZuy42NSILaWwQdgSq+QMCHFxX0a1Itrp2DT 6HyH/2Wq64TC2DZMTwzFGpa6OID2Ok7zZAyy7gMhXBoR6na4Io0ibsOA/KACOq2cBI+N vx4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brauner.io header.s=google header.b=CJ0l6l2M; 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 96si5223976ple.289.2019.05.16.09.35.12; Thu, 16 May 2019 09:35:28 -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=pass header.i=@brauner.io header.s=google header.b=CJ0l6l2M; 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 S1727213AbfEPQb4 (ORCPT + 99 others); Thu, 16 May 2019 12:31:56 -0400 Received: from mail-ed1-f68.google.com ([209.85.208.68]:35844 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726449AbfEPQbz (ORCPT ); Thu, 16 May 2019 12:31:55 -0400 Received: by mail-ed1-f68.google.com with SMTP id a8so6132149edx.3 for ; Thu, 16 May 2019 09:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brauner.io; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=KqJptEE9UZAQB57XWQVEM7jKvQBAFnzvaSb4s/mzn1A=; b=CJ0l6l2Mpk+PKRxV6CC3ospkNQL2odmgD/lDcxZ8Ypb4+nGaeq9AZr/uM46GoXb6lq 7BBRq+kJs+zgScHkY2rvjTkKeeyp8fh/t+AkjcCB4GZJuSfyL/s78vEQTiXXDGPCyEaY JYHAmmPZRE66Ly/g5c+HyJluBcBMQK+MGawapqW6L56uRvBwQ5338afFoM4Lkbx4B7Py jqgMVoH/dMGK1buK2nvKcUKOpcnjuw36NM3DzNPC0ToKkzMVEZLGddSYdO0LBWydeGyh cpfT3sYt+Wm6BvWnOQfFobv+LSfoX9aFLPSgpBIh47MlcvdMoz1ZMlLtgHxOKzm2Yn+1 7SUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=KqJptEE9UZAQB57XWQVEM7jKvQBAFnzvaSb4s/mzn1A=; b=sMMwFvNiOIGCFHF4AdOCHrvbcCrOnjY/0GKO1AlL+s3tUbcciy2dDAlTBVkmV0DnYw b7ZfnsDb9zkdOYGGWYRKgzTE62oVu+hplpokDO9+M4qlRK7TLh3YiYSp+6iA8k15J+Yf u9T1r+n2CMIu+1fbePkB9FZxKk7nZ2tIZqGCh1rZ97/9mgDyYDYhoutIREJt6i3gAuz1 APQ2qzlHnHjspJ4UsPqw2mn+QvKakv8AznCzoyJWORcbCNZ/LLRHrs9m840/cKlwywko O+neNTp4xtOy03mrahPht7s7lkXHmmHP00RH4HgBxgVMud1lx42XzdBznmyTehQ+ZuOH UYwg== X-Gm-Message-State: APjAAAXnRMMbFMQbxmgdSAOlkiJnneAxsAOxlRMgtb5MNpxPZcMWZwCx f/dicKv8DZjVVaqWGBU387ouWA== X-Received: by 2002:a50:e40f:: with SMTP id d15mr52428648edm.0.1558024313833; Thu, 16 May 2019 09:31:53 -0700 (PDT) Received: from brauner.io ([193.96.224.243]) by smtp.gmail.com with ESMTPSA id r20sm1141196ejj.4.2019.05.16.09.31.52 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 16 May 2019 09:31:53 -0700 (PDT) Date: Thu, 16 May 2019 18:31:52 +0200 From: Christian Brauner To: Al Viro Cc: David Howells , torvalds@linux-foundation.org, Arnd Bergmann , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/4] uapi, vfs: Change the mount API UAPI [ver #2] Message-ID: <20190516163151.urrmrueugockxtdy@brauner.io> References: <155800752418.4037.9567789434648701032.stgit@warthog.procyon.org.uk> <20190516162259.GB17978@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190516162259.GB17978@ZenIV.linux.org.uk> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 16, 2019 at 05:22:59PM +0100, Al Viro wrote: > On Thu, May 16, 2019 at 12:52:04PM +0100, David Howells wrote: > > > > Hi Linus, Al, > > > > Here are some patches that make changes to the mount API UAPI and two of > > them really need applying, before -rc1 - if they're going to be applied at > > all. > > I'm fine with 2--4, but I'm not convinced that cloexec-by-default crusade > makes any sense. Could somebody give coherent arguments in favour of > abandoning the existing conventions? So as I said in the commit message. From a userspace perspective it's more of an issue if one accidently leaks an fd to a task during exec. Also, most of the time one does not want to inherit an fd during an exec. It is a hazzle to always have to specify an extra flag. As Al pointed out to me open() semantics are not going anywhere. Sure, no argument there at all. But the idea of making fds cloexec by default is only targeted at fds that come from separate syscalls. fsopen(), open_tree_clone(), etc. they all return fds independent of open() so it's really easy to have them cloexec by default without regressing anyone and we also remove the need for a bunch of separate flags for each syscall to turn them into cloexec-fds. I mean, those for syscalls came with 4 separate flags to be able to specify that the returned fd should be made cloexec. The other way around, cloexec by default, fcntl() to remove the cloexec bit is way saner imho. Christian