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=-2.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 006FEC3F2C6 for ; Tue, 3 Mar 2020 20:33:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B460C20848 for ; Tue, 3 Mar 2020 20:33:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=kernel-dk.20150623.gappssmtp.com header.i=@kernel-dk.20150623.gappssmtp.com header.b="DpN9m2Xx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731831AbgCCUdF (ORCPT ); Tue, 3 Mar 2020 15:33:05 -0500 Received: from mail-io1-f68.google.com ([209.85.166.68]:40975 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730837AbgCCUdF (ORCPT ); Tue, 3 Mar 2020 15:33:05 -0500 Received: by mail-io1-f68.google.com with SMTP id m25so5126434ioo.8 for ; Tue, 03 Mar 2020 12:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NA2tNK/EVxzQPmbB3xl2CeQSQTv5FvhMkwiaUXLKu8k=; b=DpN9m2XxTJTaWFWLrmhMZf7V1GCIm2YxJek3ns+5tzeuum4/wfQwH9U2ZVWZLuJq// G2CG7cMZ0uQKq6uaHP8VVNjvib+G3RVyvjy7kH1kMoIqA6mVWk7oMvVIx0cQScQFHTeP RoxPHN++33ZpZYk7akbvYSAPI67SVi6AJikPSC380seGBqZGGSBROhHh1amdaWEiTHv/ zGWD9tdG/3wh5hGmAJH+XrjB6dYRvmmltVccjFxf1BEHVmkM1qx9gkGowI4f9RceBYG1 M1a6y9e1ip8ePcFbBhriMn4ip7GfqEce3g3YiwuI1ECwwRU+ZQnZJLtO8KOh8C43TIEv nStA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NA2tNK/EVxzQPmbB3xl2CeQSQTv5FvhMkwiaUXLKu8k=; b=EKD5/O4zZCiLNeeQYiTSuXmSAidemtB2qXdzXSjGPwmtxnh8/4IiJ7QST0X0ByrmNf e4RIyTO+E3zomGHGzM9M2guwUV+eZu5tK+e9KOKTAUbW8ouPOryONhsGaQpCIkjI9bXw sLy1OMdEY7Ebq381FdxQldv59AKXaScVKK9AltPzbGokVkrfjP6TJCbHNqSnjytWG5bf OsPvm/4OQ9grbA2PGj8D1WZHY4R24/BwitxEjje1DvwHm9a0sfYpv6DklI9JIyfajoLy s8ypq5QHIJ0lRVruEX9tsW3rt5G0DRipCBWkTjd49vYbp86nmz8QQUAwT2O7GQ01mIl5 WM+Q== X-Gm-Message-State: ANhLgQ2yc/F9qxcQ4/hbQsMndfdVJzhgCPa1AosgWzd11FM1I2SC8edB X+mipFi+CCs6zwiAImrT0SvT1w== X-Google-Smtp-Source: ADFU+vtoGIx3gKdYMLKlNybMcolvbKZ8/DjRo+oIeqMeZA+KrGcg/iqJ1ptT8MMywh+gWnklsTi+dQ== X-Received: by 2002:a6b:710c:: with SMTP id q12mr5643228iog.167.1583267584182; Tue, 03 Mar 2020 12:33:04 -0800 (PST) Received: from [192.168.1.159] ([65.144.74.34]) by smtp.gmail.com with ESMTPSA id f9sm756927ioc.70.2020.03.03.12.33.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Mar 2020 12:33:03 -0800 (PST) Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17] To: Jeff Layton , 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 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> From: Jens Axboe Message-ID: Date: Tue, 3 Mar 2020 13:33:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On 3/3/20 12:43 PM, Jeff Layton wrote: > 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. I think the one magic can work, you just have to define your chain appropriately for the case where you have multiple opens. That's true for the two magic approach as well, of course, I don't want a stack of open fds, just "last open" should suffice. I don't like the implicit close, if your op opens an fd, something should close it again. You pass it back to the application in any case for io_uring, so the app can just close it. Which means that your chain should just include a close for whatever fd you open, unless you plan on using it in the application aftwards. -- Jens Axboe