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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 40D69C55179 for ; Tue, 27 Oct 2020 07:54:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC5E422264 for ; Tue, 27 Oct 2020 07:54:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603785291; bh=OLX9wkkkI7QN9ZrSdk1YCPwT6qJ81PrNMm/jlIzDOdc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=Xfyyj4S06foEs9nYud3wYxtoes3dd6OhRhn/OOEuU4bD6VZ/ftJZ5cwUoApQ1h0s8 Sd5RthwB0N9rlTcEU6Nly9RisAkt02cc/3WWxTE4RXIYVbf3GMkrOxmKeXP9pmHKvt lxBV9lTZE7E4EiaPBWDVSe0yLHKe0jhBdZnvjTL4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2508420AbgJ0Hyu (ORCPT ); Tue, 27 Oct 2020 03:54:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:39990 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2508404AbgJ0Hyt (ORCPT ); Tue, 27 Oct 2020 03:54:49 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (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 D38452224E; Tue, 27 Oct 2020 07:54:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603785287; bh=OLX9wkkkI7QN9ZrSdk1YCPwT6qJ81PrNMm/jlIzDOdc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dvlbGcYXkY+2/Tl1QzHm/hjrA7OghdNYGiyAffPUzIQgt+Qao5l9gfiIWZv+VAv6v dHEY7oJPmPHN99DPALQbu9OVxHNhvSqr4h4nbugDRqr0IVXCOhXo/FwK/wSBmoYovD KCw6trjZMpJoOZs2x+N1xRgec5Ks4DXlrrSOWmDY= Date: Tue, 27 Oct 2020 08:55:41 +0100 From: Greg KH To: Christoph Hellwig Cc: Linus Torvalds , Al Viro , Linux Kernel Mailing List Subject: Re: problems with splice from /proc (was Linux 5.10-rc1) Message-ID: <20201027075541.GA24429@kroah.com> References: <20201027064832.GA209538@kroah.com> <20201027074911.GB29565@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201027074911.GB29565@infradead.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 27, 2020 at 07:49:11AM +0000, Christoph Hellwig wrote: > On Tue, Oct 27, 2020 at 07:48:32AM +0100, Greg KH wrote: > > On Sun, Oct 25, 2020 at 03:40:27PM -0700, Linus Torvalds wrote: > > > The most interesting - to me - change here is Christoph's setf_fs() > > > removal (it got merged through Al Viro, as you can see in my mergelog > > > below). It's not a _huge_ change, but it's interesting because the > > > whole model of set_fs() to specify whether a userspace copy actually > > > goes to user space or kernel space goes back to pretty much the > > > original release of Linux, and while the name is entirely historic (it > > > hasn't used the %fs segment register in a long time), the concept has > > > remained. Until now. > > > > I told Al this yesterday, but figured I would mention it here for others > > to see. > > > > Commit 36e2c7421f02 ("fs: don't allow splice read/write without explicit > > ops") from this patch series, is breaking the bionic test suite that > > does the following to verify that splice is working: > > > > int in = open("/proc/cpuinfo", O_RDONLY); > > ASSERT_NE(in, -1); > > > > TemporaryFile tf; > > ssize_t bytes_read = splice(in, nullptr, pipe_fds[1], nullptr, 8*1024, SPLICE_F_MORE | SPLICE_F_MOVE); > > ASSERT_NE(bytes_read, -1); > > > > Before this change, all works well but now splice fails on /proc files > > (and I'm guessing other virtual filesystems). > > > > I'll ask the bionic developers if they can change their test to some > > other file, but this is a regression and might show up in other "test > > platforms" as well. Using /proc for this is just so simple because > > these files are "always there" and don't require any housekeeping for > > test suites to worry about . > > Is this just a test or a real application? I already have the > infrastructure to support read_iter/write_iter on procfs and seq_files, > but due to the intrusiveness we decided to only fix instances on an as > needed basis. So we'll have everything ready once we pull the trigger. This is just a test, part of the bionic test suite to verify that bionic is working properly, and is run on new kernels as a verification that nothing functional broke in the kernel update. I don't know about "real applications" yet. Do you have to implement this on a per-proc-file-basis, or will it work for the whole filesystem? And are the patches public anywhere that I could test them out? thanks, greg k-h