Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp4016644ybf; Tue, 3 Mar 2020 18:02:03 -0800 (PST) X-Google-Smtp-Source: ADFU+vt5xbGGdNB7HRAnEExH727sypeN1LGHNli0nYit5vMDnHwP8VZgv3Plk9wAk6CsBbFGDvFf X-Received: by 2002:a9d:bef:: with SMTP id 102mr611381oth.225.1583287323311; Tue, 03 Mar 2020 18:02:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583287323; cv=none; d=google.com; s=arc-20160816; b=klTr4eL4ZmmF5M+tRu+6m6RD45NB7kK1uPhq/jOeHy2qpRjERAW06pOol9xSljeS87 fVLW3Lu/OO+js+zBPhKWaGIFBKAcb0SJOYCS0LPevtlXU38EKV8CL+DR7B6TzIZYNoWx 87R28aDyxD46lD9TfxrQvZlO4yLZK1fwya6/DujObshJF3weimUX7MWbaGD4veGiijo7 hrRo3BiuUUJXjibcf0xHbJaEMnyYi3s/Rs2zMerv3deUm9BZ+voz77ktZYS+3PlPszW9 LG+SsBGhVxOQYVIpdsrxJJZLDJS/0BjFMfUAQqBgND1uykR/LePgbRIY0cmizbMxT1a/ RoNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature:dkim-signature; bh=ow4wwXQIg9ovCqqBjjjTQMs5ZKSMH9h5wtQ/U1CNI/I=; b=HQAuK+9t4Wk3s/sK2u69Cu3Z1x+yf9XqN8EwCrNwCzB1RMcG0T1W71ur/OcpgnJdd2 /eV4i3VN3QR5punVq8d+aldCe08Lutu1MFEpQvrAwzuPKfAIFLV2NF3bn/TriRBOeo4O cCAm2EkyRBlN6utkxMXt/VxkHGPdp6J3cv5putjz6Ua3VS+1kv0Qn11UYs8vLbn+IArh gr4c5vbDGPQQAhw6/F5jWGvCw6SK55YMXUZmQwHe0hgj/v5h1eXcCCsfFNwuUjNFeNMK mfA6Ez4ecYRIE9TcyqWLFyD7GBYmgI5wXH13UyMqqCfRCg0dv2UREwo+Uf2r+FIhT6LC 5T+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@themaw.net header.s=fm2 header.b=vDPbhtWT; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=gctaaglv; 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 i3si250503otc.272.2020.03.03.18.01.49; Tue, 03 Mar 2020 18:02:03 -0800 (PST) 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=@themaw.net header.s=fm2 header.b=vDPbhtWT; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=gctaaglv; 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 S2387411AbgCDCBp (ORCPT + 99 others); Tue, 3 Mar 2020 21:01:45 -0500 Received: from new3-smtp.messagingengine.com ([66.111.4.229]:44619 "EHLO new3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727725AbgCDCBp (ORCPT ); Tue, 3 Mar 2020 21:01:45 -0500 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id D50014BCC; Tue, 3 Mar 2020 21:01:43 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 03 Mar 2020 21:01:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=themaw.net; h= message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; s=fm2; bh= ow4wwXQIg9ovCqqBjjjTQMs5ZKSMH9h5wtQ/U1CNI/I=; b=vDPbhtWTqiBiUQry B1qXySlymx6WucS60DbKY/k3yxXdgkijDpLdraCuA6qqY/1rusUCZvinzKpoXQlT vQK51RWEHlRcQm9Wu7/ygpykpyYACaLGWin8w3PubywD5mZ+i2kjY3nRILBDlNb/ 2J5cLHfMj3r/BHP3sPRIJlI1ou13L36kJmvVXaoY2wPCW+Egymg8oriIt9FAYiSj RcDhx3MoxwDpUSi6a+FhzYAKoYo3y5oR17IYbmH9jscxV5Qog/TX2BsP/6pPiEfx jl7vo3Y+vVfd0kfuAqadwIOAxFQaG3z/X02VYL+0pgH1KXR1i7yPomSe1tFz4UUM v2ZhGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=ow4wwXQIg9ovCqqBjjjTQMs5ZKSMH9h5wtQ/U1CNI /I=; b=gctaaglvDbkWZxX8IvhuEc3hMbS93cVej20svOfL42SOTof7DxnnnIJ2E EfCwjiUtphQ61Xy+RfujGBtVdIwNZ9JD9iSPb9mxSJvSbu8gmQM4JkL+n1iZU4vO kdUZqMQ2hz7C83cn/EtrLto5BxzeYlAWxvl52tD0MyC9k48Z/6Nox5IkUyMFtvxl RjJt51LcK7XBIm8iFl1pPR6hM7OO7kWaSBUJdsKxRGRnd216QdX2kXfH32L+wCSS 0J99u0agy4eJyFJSzXCPNrfiCAs8P341khlZGoE6EiQVMl17EDMSKPv++2fxLfcK KSITryfZXHbSItn+co5uUDPOxUcDA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtjedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkffuhffvffgjfhgtfggggfesthejredttderjeenucfhrhhomhepkfgrnhcu mfgvnhhtuceorhgrvhgvnhesthhhvghmrgifrdhnvghtqeenucfkphepuddukedrvddtke drudektddrvddtvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehrrghvvghnsehthhgvmhgrfidrnhgvth X-ME-Proxy: Received: from mickey.themaw.net (unknown [118.208.180.202]) by mail.messagingengine.com (Postfix) with ESMTPA id C9AA93280063; Tue, 3 Mar 2020 21:01:37 -0500 (EST) Message-ID: <33d900c8061c40f70ba2b9d1855fd6bd1c2b68bb.camel@themaw.net> Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17] From: Ian Kent To: Greg Kroah-Hartman , Karel Zak Cc: Miklos Szeredi , David Howells , Christian Brauner , James Bottomley , Steven Whitehouse , Miklos Szeredi , viro , Christian Brauner , Jann Horn , "Darrick J. Wong" , Linux API , linux-fsdevel , lkml Date: Wed, 04 Mar 2020 10:01:33 +0800 In-Reply-To: <20200303130347.GA2302029@kroah.com> References: <1582644535.3361.8.camel@HansenPartnership.com> <20200228155244.k4h4hz3dqhl7q7ks@wittgenstein> <107666.1582907766@warthog.procyon.org.uk> <0403cda7345e34c800eec8e2870a1917a8c07e5c.camel@themaw.net> <1509948.1583226773@warthog.procyon.org.uk> <20200303113814.rsqhljkch6tgorpu@ws.net.home> <20200303130347.GA2302029@kroah.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) 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 14:03 +0100, Greg Kroah-Hartman wrote: > On Tue, Mar 03, 2020 at 12:38:14PM +0100, Karel Zak wrote: > > On Tue, Mar 03, 2020 at 10:26:21AM +0100, Miklos Szeredi wrote: > > > No, I don't think this is going to be a performance issue at all, > > > but > > > if anything we could introduce a syscall > > > > > > ssize_t readfile(int dfd, const char *path, char *buf, size_t > > > bufsize, int flags); > > > > off-topic, but I'll buy you many many beers if you implement it ;- > > ), > > because open + read + close is pretty common for /sys and /proc in > > many userspace tools; for example ps, top, lsblk, lsmem, lsns, > > udevd > > etc. is all about it. > > Unlimited beers for a 21-line kernel patch? Sign me up! > > Totally untested, barely compiled patch below. > > Actually, I like this idea (the syscall, not just the unlimited > beers). > Maybe this could make a lot of sense, I'll write some actual tests > for > it now that syscalls are getting "heavy" again due to CPU vendors > finally paying the price for their madness... The problem isn't with open->read->close but with the mount info. changing between reads (ie. seq file read takes and drops the needed lock between reads at least once). The problem is you don't know the buffer size needed to get this in one hit, how is this different to read(2)? > > thanks, > > greg k-h > ------------------- > > > diff --git a/arch/x86/entry/syscalls/syscall_64.tbl > b/arch/x86/entry/syscalls/syscall_64.tbl > index 44d510bc9b78..178cd45340e2 100644 > --- a/arch/x86/entry/syscalls/syscall_64.tbl > +++ b/arch/x86/entry/syscalls/syscall_64.tbl > @@ -359,6 +359,7 @@ > 435 common clone3 __x64_sys_clone3/ptregs > 437 common openat2 __x64_sys_openat2 > 438 common pidfd_getfd __x64_sys_pidfd_getfd > +439 common readfile __x86_sys_readfile > > # > # x32-specific system call numbers start at 512 to avoid cache > impact > diff --git a/fs/open.c b/fs/open.c > index 0788b3715731..1a830fada750 100644 > --- a/fs/open.c > +++ b/fs/open.c > @@ -1340,3 +1340,23 @@ int stream_open(struct inode *inode, struct > file *filp) > } > > EXPORT_SYMBOL(stream_open); > + > +SYSCALL_DEFINE5(readfile, int, dfd, const char __user *, filename, > + char __user *, buffer, size_t, bufsize, int, flags) > +{ > + int retval; > + int fd; > + > + if (force_o_largefile()) > + flags |= O_LARGEFILE; > + > + fd = do_sys_open(dfd, filename, flags, O_RDONLY); > + if (fd <= 0) > + return fd; > + > + retval = ksys_read(fd, buffer, bufsize); > + > + __close_fd(current->files, fd); > + > + return retval; > +}