From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EA84C3F2D1 for ; Tue, 3 Mar 2020 19:43:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1657020CC7 for ; Tue, 3 Mar 2020 19:43:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583264628; bh=DCL8ykDk5TOwzA/Lva4sncSGdbnsdat+IzdI+ZVWZEM=; h=Subject:From:To:Cc:Date:In-Reply-To:References:List-ID:From; b=k3njmZJf/MvYko3z6uW05WKK24a0qdOhyX2C6ar0y00UiQQgL56eyd/VlyGRPXdEz ETYmgX92nPZ96B7yi5ksf40w8NSMRBLICZe4Qx38i18AzTGikWAloroHengQoJ00WF tRDvIrXf8jAwtCdbTfC5bacqTc2IvjzuKbhzXTvI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731065AbgCCTnr (ORCPT ); Tue, 3 Mar 2020 14:43:47 -0500 Received: from mail.kernel.org ([198.145.29.99]:56852 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728180AbgCCTnr (ORCPT ); Tue, 3 Mar 2020 14:43:47 -0500 Received: from tleilax.poochiereds.net (68-20-15-154.lightspeed.rlghnc.sbcglobal.net [68.20.15.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 4610C20870; Tue, 3 Mar 2020 19:43:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583264626; bh=DCL8ykDk5TOwzA/Lva4sncSGdbnsdat+IzdI+ZVWZEM=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=nsnxIjROrEOodcoUUfkk/9UAGrJoxMgXXvExx4ZJ1oy3uKRSiHXRuNctJDwDeDirA 7ZET8GMx3MYvCWFDkyjivIzeX3cJBF06lF6UjdaVvg/2ggQmcZ9XdalkwXSBYUv4av dCAXLU/OlF9SpunpiAM6TNnLQnQyInzDnUUfblgA= Message-ID: Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17] From: Jeff Layton To: Jens Axboe , Greg Kroah-Hartman , Jann Horn Cc: Miklos Szeredi , Karel Zak , David Howells , Ian Kent , Christian Brauner , James Bottomley , Steven Whitehouse , Miklos Szeredi , viro , Christian Brauner , "Darrick J. Wong" , Linux API , linux-fsdevel , lkml Date: Tue, 03 Mar 2020 14:43:44 -0500 In-Reply-To: References: <1509948.1583226773@warthog.procyon.org.uk> <20200303113814.rsqhljkch6tgorpu@ws.net.home> <20200303130347.GA2302029@kroah.com> <20200303131434.GA2373427@kroah.com> <20200303134316.GA2509660@kroah.com> <20200303141030.GA2811@kroah.com> <20200303142407.GA47158@kroah.com> <030888a2-db3e-919d-d8ef-79dcc10779f9@kernel.dk> <7a05adc8-1ca9-c900-7b24-305f1b3a9b86@kernel.dk> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-03-03 at 12:23 -0700, Jens Axboe wrote: > On 3/3/20 12:02 PM, Jeff Layton wrote: > > Basically, all you'd need to do is keep a pointer to struct file in the > > internal state for the chain. Then, allow userland to specify some magic > > fd value for subsequent chained operations that says to use that instead > > of consulting the fdtable. Maybe use -4096 (-MAX_ERRNO - 1)? > > BTW, I think we need two magics here. One that says "result from > previous is fd for next", and one that says "fd from previous is fd for > next". The former allows inheritance from open -> read, the latter from > read -> write. > Do we? I suspect that in almost all of the cases, all we'd care about is the last open. Also if you have unrelated operations in there you still have to chain the fd through somehow to the next op which is a bit hard to do with that scheme. I'd just have a single magic carveout that means "use the result of last open call done in this chain". If you do a second open (or pipe, or...), then that would put the old struct file pointer and drop a new one in there. If we really do want to enable multiple opens in a single chain though, then we might want to rethink this and consider some sort of slot table for storing open fds. -- Jeff Layton