From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 12 Jan 2017 09:16:20 +0000 From: Al Viro To: Jeff Layton Cc: Johannes Thumshirn , "J . Bruce Fields" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, mbenes@suse.cz, jack@suse.cz Subject: Re: [PATCH RESEND] splice: introduce FMODE_SPLICE_READ and FMODE_SPLICE_WRITE Message-ID: <20170112091620.GV1555@ZenIV.linux.org.uk> References: <20170111095139.17783-1-jthumshirn@suse.de> <1484137213.2621.6.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1484137213.2621.6.camel@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: On Wed, Jan 11, 2017 at 07:20:13AM -0500, Jeff Layton wrote: > On Wed, 2017-01-11 at 10:51 +0100, Johannes Thumshirn wrote: > > Introduce FMODE_SPLICE_READ and FMODE_SPLICE_WRITE. These modes check > > whether it is legal to read or write a file using splice. Both get > > automatically set on regular files and are not checked when a 'struct > > fileoperations' includes the splice_{read,write} methods. > > > > Could you add a description of the problem that this solves? I assume > you hit a problem trying to splice to/from a non-regular file, but it'd > be good to know what that problem was. Insane ->write() instances, basically. I'm not at all convinced that it's a good idea - sure, we can go and mark sane ones as such one-by-one, but it's a _lot_ of code churn and insane ones are very few. Moreover, I would argue that the right way to handle that is to reject any new instances of that insanity - splice or no splice, write(2) that includes userland pointers in payload and dereferences them is not fit to live. /dev/sg, /dev/bsg and infinibarf are examples of really bad APIs; sure, we can't kill them off (at least /dev/sg is used by a bunch of userland programs and all of them expect that semantics), but that doesn't excuse any new drivers trying to introduce the same.