Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1571977ybz; Thu, 23 Apr 2020 01:10:50 -0700 (PDT) X-Google-Smtp-Source: APiQypJIFRv5Gw73j3BUiiIaOwjVe8oQNClmp74oChlMdljZZnahiBVviQLZr93y0gudIwfmvt8t X-Received: by 2002:a50:dac9:: with SMTP id s9mr1757361edj.313.1587629450776; Thu, 23 Apr 2020 01:10:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587629450; cv=none; d=google.com; s=arc-20160816; b=qL8Jg3la1GWY2cTf9DS06VsuMl+jgdfnvjHQmtEQ40Mi6MfMwlz6lWDpWBKAWmQMGE R/0mNSC4jrFDQQRH4JZBFZS9LTlIbWCv//y9LeYAFdneMgQpVH1qag8WZeD8IeOxfIBW WgT5G2mBe0X96LitkEV069ZKfdNAdXmshUq0F0rpeYhJUv/kRAVdoYX4gHHBgmtjlbxs eImI/zJ+qpDQxDaVSA8EhoQfdejEXevAOVUlppuStrx0Y9T+j4iLVtkCFlJmjI1vxACS kg+72BlicH33sPMEi52D2Q7iIiEPWCkj7EVeNR9fVF4FzOMDMX13DrCOtenTfZm8RJj5 uCNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=EEfZgCV7rd6LD56zaTesiyfgYP5TuOlAwqvQW/n9f7Y=; b=Frvb0C74iJqqKu22FMGyrbu2LgNhNIR6cjOT06u39WfJkeMyO0a2WJkhwAFP5ye5OW lt5S+eWdCqnFd6APscYFQv2DLl6D+ZYwZZ8ADTSTqOQy868aMuya2oH7jsbhV7YdH1Yv rB+yyiwOf8BhHEkeT/nKHVVxo+LmOwBOWDkSet1Tvuhovvx8psX4UEBzZrN/UjTiQmSt hw+su+qWUWfW9/b6ALL1plBTHBeq7BU6AyA7IgMqczzQxbKblgHiR/LiM8au0x/+aeth gEE8UkoA5vJOl/2iRfrb6Gu5jj8AI7Efjqt8W5upvhWsjczeUcQjwrvPMKZsVl8XqmQg TAVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c4si808409ejk.442.2020.04.23.01.10.27; Thu, 23 Apr 2020 01:10:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726495AbgDWIGy (ORCPT + 99 others); Thu, 23 Apr 2020 04:06:54 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:52927 "EHLO relay6-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725863AbgDWIGx (ORCPT ); Thu, 23 Apr 2020 04:06:53 -0400 X-Originating-IP: 50.39.163.217 Received: from localhost (50-39-163-217.bvtn.or.frontiernet.net [50.39.163.217]) (Authenticated sender: josh@joshtriplett.org) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 97775C000C; Thu, 23 Apr 2020 08:06:46 +0000 (UTC) Date: Thu, 23 Apr 2020 01:06:44 -0700 From: Josh Triplett To: Miklos Szeredi Cc: Michael Kerrisk , io-uring@vger.kernel.org, "linux-fsdevel@vger.kernel.org" , lkml , Alexander Viro , Arnd Bergmann , Jens Axboe , Aleksa Sarai , linux-man , Linux API Subject: Re: [PATCH v5 2/3] fs: openat2: Extend open_how to allow userspace-selected fds Message-ID: <20200423080644.GA171696@localhost> References: <9873b8bd7d14ff8cd2a5782b434b39f076679eeb.1587531463.git.josh@joshtriplett.org> <20200423004807.GC161058@localhost> <20200423044226.GH161058@localhost> <20200423073310.GA169998@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 23, 2020 at 09:45:45AM +0200, Miklos Szeredi wrote: > On Thu, Apr 23, 2020 at 9:33 AM Josh Triplett wrote: > > > What are the plans for those syscalls that don't easily lend > > > themselves to this modification (such as accept(2))? > > > > accept4 has a flags argument with more flags available, so it'd be > > entirely possible to cleanly extend it further without introducing a new > > version. > > Variable argument syscalls, you are thinking? That or repurposing an existing pointer-sized argument as an open_how-style struct, yes. But in any case, I'm not proposing that; I'm proposing changes to the existing highly extensible openat2 syscall. > > > I mean, you could open the file descriptor outside of io_uring in such > > > cases, no? > > > > I would prefer to not introduce that limitation in the first place, and > > instead open normal file descriptors. > > > > > The point of O_SPECIFIC_FD is to be able to perform short > > > sequences of open/dosomething/close without having to block and having > > > to issue separate syscalls. > > > > "close" is not a required component. It's entirely possible to use > > io_uring to open a file descriptor, do various things with it, and then > > leave it open for subsequent usage via either other io_uring chains or > > standalone syscalls. > > If this use case arraises, This wasn't a hypothetical "someone might want this". I'm stating that this is a requirement I'm seeking to meet with this patch series, and one I intend to use. The primary use case is interoperability with other code using file descriptors and not using io_uring.