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=-11.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 A8AF7C3F2CD for ; Tue, 3 Mar 2020 14:13:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7E9BA20866 for ; Tue, 3 Mar 2020 14:13:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="jFnI/p5s" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729219AbgCCON4 (ORCPT ); Tue, 3 Mar 2020 09:13:56 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:44739 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729153AbgCCONz (ORCPT ); Tue, 3 Mar 2020 09:13:55 -0500 Received: by mail-ot1-f67.google.com with SMTP id v22so3054518otq.11 for ; Tue, 03 Mar 2020 06:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3rR9D2f+H/e0fSVL00Hp9urV4+rGAWYmYmqAOeH9QiI=; b=jFnI/p5sGaE8Le8fiAMY42PMLKHkTRTf1QlMJPXMCzYAPy8+oJUNnB2h44tAjiv4WG E9NYrTbliI2We1ehAL0n+Hp9Uz00HJzBmAhv3SsJrGYr5I8MUaiLc9NcTAhanR5CacZG 4nZqO6O/Nw1BwSiM3dynOT07TZhRVAMtw54DqT2ZNy6GlXhYvAgYGea/T1S+AWSkeBn5 fgGolr4CvH475/Z9IH+BEEgzi9UE3ij4Bo4SOMnhHoU4hSdxHnlbdOQmD4hKG1hAgPND qG4XEhYVHTYOSDJvJtAYMaKtgNWLtGbBsegtIJruZParsVY787NBAVWV/6XtuB4GAc+v D2gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3rR9D2f+H/e0fSVL00Hp9urV4+rGAWYmYmqAOeH9QiI=; b=l0KS5akAU1GfxqyIqD9xjX9VHC+TPoG+eFJbGELPhCq1eHYOqC94GsUbagDfQm/yVy ZfwHph41ZbRKgrgJdf+mRh/ii0PDrN7FEvA242V8AEOyapfe5fTW9zxoJCGIxaTHR9qZ pZ6McbvyzwBRQIQlMnpOCiHqrubOVe3ZpDTWkHHuAt/Sq1Y9LwWNmOd+wHQRvLSO4KSg G5vKOb0dQ/qj9m5xVyNr4Wx906X6Ho6pgmXlqcUnm1AHNw+dBn8oAogroRwL8/PHbvCM f8cP8+dMpgN1VRg2sdxHR1z+Svip5eF7cjHNQSAyOGAhl1ZeHyGYErMxbL0XuFujVVh7 FIrw== X-Gm-Message-State: ANhLgQ3SX6gkYPHfOk3E8loOHbKKfcONuv/J2F4gYlLAp3p9ldbDzS4t iXZQ4qXomzKbjsRbdnxXK3FRuGyhTbjQm/CP0K1HkA== X-Google-Smtp-Source: ADFU+vufO6VrHobavK+ZbGNW4cEy5kqvLT7wd3WR4i93yBzOJEjSq9F6npSTRWuvRj2vM5/2ga1joTBYwWqaeS0xT0I= X-Received: by 2002:a9d:7358:: with SMTP id l24mr837663otk.228.1583244833306; Tue, 03 Mar 2020 06:13:53 -0800 (PST) MIME-Version: 1.0 References: <0403cda7345e34c800eec8e2870a1917a8c07e5c.camel@themaw.net> <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> In-Reply-To: <20200303141030.GA2811@kroah.com> From: Jann Horn Date: Tue, 3 Mar 2020 15:13:26 +0100 Message-ID: Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17] To: Greg Kroah-Hartman 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 , Jens Axboe 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 Tue, Mar 3, 2020 at 3:10 PM Greg Kroah-Hartman wrote: > > On Tue, Mar 03, 2020 at 02:43:16PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Mar 03, 2020 at 02:34:42PM +0100, Miklos Szeredi wrote: > > > On Tue, Mar 3, 2020 at 2:14 PM Greg Kroah-Hartman > > > wrote: > > > > > > > > Unlimited beers for a 21-line kernel patch? Sign me up! > > > > > > > > > > Totally untested, barely compiled patch below. > > > > > > > > Ok, that didn't even build, let me try this for real now... > > > > > > Some comments on the interface: > > > > Ok, hey, let's do this proper :) > > Alright, how about this patch. > > Actually tested with some simple sysfs files. > > If people don't strongly object, I'll add "real" tests to it, hook it up > to all arches, write a manpage, and all the fun fluff a new syscall > deserves and submit it "for real". Just FYI, io_uring is moving towards the same kind of thing... IIRC you can already use it to batch a bunch of open() calls, then batch a bunch of read() calls on all the new fds and close them at the same time. And I think they're planning to add support for doing open()+read()+close() all in one go, too, except that it's a bit complicated because passing forward the file descriptor in a generic way is a bit complicated. > It feels like I'm doing something wrong in that the actuall syscall > logic is just so small. Maybe I'll benchmark this thing to see if it > makes any real difference... > > thanks, > > greg k-h > > From: Greg Kroah-Hartman > Subject: [PATCH] readfile: implement readfile syscall > > It's a tiny syscall, meant to allow a user to do a single "open this > file, read into this buffer, and close the file" all in a single shot. > > Should be good for reading "tiny" files like sysfs, procfs, and other > "small" files. > > There is no restarting the syscall, am trying to keep it simple. At > least for now. > > Signed-off-by: Greg Kroah-Hartman [...] > +SYSCALL_DEFINE5(readfile, int, dfd, const char __user *, filename, > + char __user *, buffer, size_t, bufsize, int, flags) > +{ > + int retval; > + int fd; > + > + /* Mask off all O_ flags as we only want to read from the file */ > + flags &= ~(VALID_OPEN_FLAGS); > + flags |= O_RDONLY | O_LARGEFILE; > + > + fd = do_sys_open(dfd, filename, flags, 0000); > + if (fd <= 0) > + return fd; > + > + retval = ksys_read(fd, buffer, bufsize); > + > + __close_fd(current->files, fd); > + > + return retval; > +} If you're gonna do something like that, wouldn't you want to also elide the use of the file descriptor table completely? do_sys_open() will have to do atomic operations in the fd table and stuff, which is probably moderately bad in terms of cacheline bouncing if this is used in a multithreaded context; and as a side effect, the fd would be inherited by anyone who calls fork() concurrently. You'll probably want to use APIs like do_filp_open() and filp_close(), or something like that, instead.