Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp504137pxj; Fri, 7 May 2021 13:33:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxGPkEdYeya6NpXti4/9UM0beQ19f1tIso8/RALa1ExH3x2zi/5fZAV5Usj/i8P7kiyAEED X-Received: by 2002:a05:6402:5a:: with SMTP id f26mr13645432edu.306.1620419595214; Fri, 07 May 2021 13:33:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620419595; cv=none; d=google.com; s=arc-20160816; b=e0Sx80ponnyuymemdS02l9VU8lXaV23+hXRLU9LhrJQJ3mFuv3M3XD4FjV8MweEviZ M/6ojymQp9OSjQ4BJnL8uQ82q1udEe1GCPg8Xo3J2ekyf09D8mtG9OyREsLHHN2z6rzT ftY/lHnSShQNxkCXpZ59T2WGaT/COeDWGK7B4hozZCKR7QEQAot4k56Sqjfc11tDxaqd gSghFcTiIGLq9Ca5QVy9xY8oxpIk9u+PzWMWJZkSgR0rFXYY5qlpAQZcU5AZcC7/bTiw tYNydQ9AGEmJB7fCKBthdHGG/p0kaoIkBiOewQdh54w7JSTK/uNL2rRVYSlrLysniib/ VzMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=oaVV5LMbhwDjsGzkc17Ksd0bYDOhhjaNckf2WDp0n4Y=; b=D78TYB0YWfLj8+EPye4SfaGK756ILEyNhkBeuO//WROnGOUzHFCFGp9IFy1F+7xguF Z+NCR/VIqRgTRmJHfzidw7QeQRvhzabLufkT11Z/op4WLZTpUXX8Rv2cQ1m6gSwkjm9i d0iI6jNAS+gnIGcbxOAi9/otmPBugyQgMu4fxhD4ZGJe6WC7PgADPN71ktf4QfMSOi7C 8TW/9zH04SuKB9HtvlhGKZMm8R4/l/3gNUyXH+XtLjXHFqcTy5TCIXpx8X/ZwOmaxGcg 1y4bTG83Rt4FZu/dWrw+qBpb4jwEzfRjxrRyzT9g7OFeI0OHWNUHs2vwjo4FTSbgPWhQ vXNg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y20si2937082edt.290.2021.05.07.13.32.49; Fri, 07 May 2021 13:33:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230097AbhEGUck (ORCPT + 99 others); Fri, 7 May 2021 16:32:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229675AbhEGUck (ORCPT ); Fri, 7 May 2021 16:32:40 -0400 Received: from zeniv-ca.linux.org.uk (zeniv-ca.linux.org.uk [IPv6:2607:5300:60:148a::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20F7BC061574; Fri, 7 May 2021 13:31:40 -0700 (PDT) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94 #2 (Red Hat Linux)) id 1lf78G-00CNE3-Em; Fri, 07 May 2021 20:31:32 +0000 Date: Fri, 7 May 2021 20:31:32 +0000 From: Al Viro To: Linus Torvalds Cc: Kees Cook , Colin Ian King , Christoph Hellwig , Johannes Berg , linux-fsdevel , LKML Subject: Re: splice() from /dev/zero to a pipe does not work (5.9+) Message-ID: References: <2add1129-d42e-176d-353d-3aca21280ead@canonical.com> <202105071116.638258236E@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 07, 2021 at 12:29:44PM -0700, Linus Torvalds wrote: > On Fri, May 7, 2021 at 12:17 PM Al Viro wrote: > > > > Umm... That would do wonders to anything that used to do > > copy_to_user()/clear_user()/copy_to_user() and got converted > > to copy_to_iter()/iov_iter_zero()/copy_to_iter()... > > I didn't mean for iov_iter_zero doing this - only splice_read_zero(). > > > Are you sure we can shove zero page into pipe, anyway? > > IIRC, get_page()/put_page() on that is not allowed, > > That's what the > > buf->ops = &zero_pipe_buf_ops; > > is for. The zero_pipe_buf_ops would have empty get and release > functions, and a 'steal' function that always returns false. > > That's how the pipe pages are supposed to work: there are people who > put non-page data (ie things like skbuff allocations etc) into a > splice pipe buffer. It's why we have those "ops" pointers. Supposed to - sure, but I'd like to verify that they actually do work that way before we go there. Let me RTFS a bit...