Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp451342pxj; Fri, 7 May 2021 12:18:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxKrMdC1GzVNshQNCIcIfSw0+rF8ZRLOIiR6pfd5nasPuIM69o49QcBBQVXtz9NrRAtVlBu X-Received: by 2002:a17:90a:3849:: with SMTP id l9mr12186865pjf.108.1620415128970; Fri, 07 May 2021 12:18:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620415128; cv=none; d=google.com; s=arc-20160816; b=Aog848YgqD/j5ZKAI/Vs9DjTTjdLvIYv/evQpuL/Zah1lQzIP4iAx+EsY8Wlb0i3tN Z/kr83RRAcWA/yZIJvZJQVQSt3wegoVk2ZS3EjNFN31/Rp0t74BRRMSl+VZjLGW+u9Uu 57Wj5HQOhB/T4bcXhtlJVnBmQe/QoH4HXsmcm4oiBqCYS8Zjd/nsvjeBR7q1f9k1dI5o 3Vm4xNmuNXFbhc1CxRbteaNzgG2QaH52ZQY+GZ211Yzyw7BxJ/WqWGzo01V385Dcaxt3 xG/h+EvZlFEtngag17F2xzxPkhh+iJHIS+UNkqFPfu/yyPfprY9Cc3oxEmvlimYvmQbw aGCg== 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=akSMXPGjfxJXtdFTu58VHzmK1omKRtL9oe9zWUU7gn4=; b=qBQQXXb8DvYuv3sHrwMq03+Qxg61qOTucPXXx0nHZ8Kgh+tRwkmcenBbBpl8s6zRoE 3QzBt8ngPWjqwVbvYHU7erx+Nz16PTUuPWB4kppx6om3ojEEVi1WHei65n6c/Ol1vFJz XuPbnCB3ee+BLhobw66OMO0qg9soW4Lhia9QPLjYCAXNxjV0k8pgIHYsojpuLtJ3lb/K 6T1UtPSySlsUItEihoHMKdU/BpagZ+JY+0A/lNVIK3nd00S3T9Updh1qB4OVuwf21qnS nX5YjxtC5aQkWQxAoGiCyhh7oD9XmuLYi2fZYgBqjZwXZrJqx9MVZrYUGqQO+RVb/KKs teEg== 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 v16si7581373plg.264.2021.05.07.12.18.36; Fri, 07 May 2021 12:18:48 -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 S229675AbhEGTTC (ORCPT + 99 others); Fri, 7 May 2021 15:19:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229542AbhEGTTB (ORCPT ); Fri, 7 May 2021 15:19:01 -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 8FAEDC061574; Fri, 7 May 2021 12:18:01 -0700 (PDT) Received: from viro by zeniv-ca.linux.org.uk with local (Exim 4.94 #2 (Red Hat Linux)) id 1lf5yy-00CMNR-Ra; Fri, 07 May 2021 19:17:52 +0000 Date: Fri, 7 May 2021 19:17:52 +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:06:31PM -0700, Linus Torvalds wrote: > That said - looking at the current 'pipe_zero()', it uses > 'push_pipe()' to actually allocation regular pages, and then clear > them. > > Which is basically what a generic_file_splice_read() would do, and it > feels incredibly pointless and stupid to me. > > I *think* we should be able to just do something like > > len = size; > while (len > 0) { > struct pipe_buffer *buf; > unsigned int tail = pipe->tail; > unsigned int head = pipe->head; > unsigned int mask = pipe->ring_size - 1; > > if (pipe_full(head, tail, pipe->max_usage)) > break; > buf = &pipe->bufs[iter_head & p_mask]; > buf->ops = &zero_pipe_buf_ops; > buf->page = ZERO_PAGE(0); > buf->offset = 0; > buf->len = min_t(ssize_t, len, PAGE_SIZE); > len -= buf->len; > pipe->head = head+1; > } > return size - len; > > but honestly, I haven't thought a lot about it. > > Al? This is another of those "right up your alley" things. 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()... Are you sure we can shove zero page into pipe, anyway? IIRC, get_page()/put_page() on that is not allowed, and I'm not at all sure that nothing in e.g. fuse splice-related logics would go ahead an do just that. Or am I confused about the page refcounting for those?