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 819C7C4363A for ; Tue, 27 Oct 2020 06:49:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 23EF620B1F for ; Tue, 27 Oct 2020 06:49:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603781353; bh=97Q1QKetcOCCOZuLlUxWMP/P31O7i+94Yd9QC1fy3jE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=vrGkGwAXA47+Oh1DxD8iJ12cNUFE25USszIby3RlEwHxy9W+p5lWXsopchx4DA7Ns XrhqAiyLRWUHORf1CmkZjnb0iEiwgjkHMNOlYI2kPA28AJgjyWBPJCz6U7cbzwphZ/ riRau99e4a8tNY51GIMPw6bdW2iK2MFbpPyZ/ypQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729153AbgJ0Gsh (ORCPT ); Tue, 27 Oct 2020 02:48:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:33116 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728248AbgJ0Gsg (ORCPT ); Tue, 27 Oct 2020 02:48:36 -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 5A62120B1F; Tue, 27 Oct 2020 06:48:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603781316; bh=97Q1QKetcOCCOZuLlUxWMP/P31O7i+94Yd9QC1fy3jE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=K4TM2cAtnqmMk68y6nVhx0DArc/NAIZVMOC9s86GT6K2G+bneTXBM2kzIQ0Bdgjo+ Im/CG9912AKxAg9C0aAr+93gCEEkCE1YOnjCMPrJYjvcdVynQJAW5RgvB496p9+Lyt 2N3I7/ZwTGccJC2T4bG4yQESbIyp1Qd5pWG7+ufU= Date: Tue, 27 Oct 2020 07:48:32 +0100 From: Greg KH To: Linus Torvalds , Christoph Hellwig Cc: Al Viro , Linux Kernel Mailing List Subject: problems with splice from /proc (was Linux 5.10-rc1) Message-ID: <20201027064832.GA209538@kroah.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 . thanks, greg k-h