Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp2062612ybg; Thu, 30 Jul 2020 09:23:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzL9AfGFQc4aFAac2cQvWlg8GwrwCoIgJs9E83eaAaGY6QSZELXbVmkfqkRZ0lSi/eKMkky X-Received: by 2002:a17:906:1c0e:: with SMTP id k14mr3290945ejg.479.1596126233166; Thu, 30 Jul 2020 09:23:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596126233; cv=none; d=google.com; s=arc-20160816; b=dZ38fMx2nKyxgpbgjfmNrGYpDrKLDB6IjWHkeCSfgDFLa7cuz3RgQL6JWWb+KhZNUl AogrMZnfXXrIe3YbvmfvKb+4WMKT+c/d3PIAJxa4pmeqUoXXSpbQW4n2BI3KvVi1Ten5 XioaqkM4cj08Yarv7PKVs0oVECBsJALFMgMBoZiN/2lC2pSioo+mxyzVJsJvuL4KaIQQ KFXBRmalKS2Gvc88cHcr0mAu9iLrU8vL6XL1VZhlBIm5f2xMf9ehZ2RYrZlfjxSXDQtQ gdgcs+KPHj8+4zkLDSfMbVBBMM4dR3tBHiqlmubH+OP1LiPQBZkTFm1ZcQsn3czy2RmS EluQ== 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=2YFjmADDT7zLnBnyAQwGWMe4qadsQ61Keg/eRUdMvSw=; b=jDG9w2C62RP0D0r1RmyqbpesMbwJHuSipr/S2OwUEbP8nbE5NGHGqZ/bSmV4qEOwt2 s2cPuFjf1VG3xaRiUlASevVNXUSUKfvtUtxduqa1gnq6QWe/m9auLmGgMI9cBShTJ6o2 KtWnJzffpwHR1fXu/n37IUR8RuqZDyAg8dE8j6nZH7DuvRtPyA6SL5aD+/Hz/DDjEyZA 4cDbrI/3bS3rOwj1Vg6HmaACFosg5SdsAJ4zTLTnEcs6U+vjE0BEsYZVVe88L2WzxhA6 +NumylEVIyr/i8HZAI1aX721F6qZRUyOqX+Vmw8pzzIzfDrfXBpc2D6T1JIEmfX4Onpd CaoQ== 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 x15si3368515eje.180.2020.07.30.09.23.29; Thu, 30 Jul 2020 09:23:53 -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 S1729965AbgG3QWc (ORCPT + 99 others); Thu, 30 Jul 2020 12:22:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726275AbgG3QWb (ORCPT ); Thu, 30 Jul 2020 12:22:31 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D17EC061574; Thu, 30 Jul 2020 09:22:31 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k1BJz-005lAt-Uv; Thu, 30 Jul 2020 16:22:20 +0000 Date: Thu, 30 Jul 2020 17:22:19 +0100 From: Al Viro To: Christoph Hellwig Cc: Linus Torvalds , Stephen Rothwell , Luis Chamberlain , Matthew Wilcox , Kees Cook , Iurii Zaikin , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH 22/23] fs: default to generic_file_splice_read for files having ->read_iter Message-ID: <20200730162219.GC1236603@ZenIV.linux.org.uk> References: <20200707174801.4162712-1-hch@lst.de> <20200707174801.4162712-23-hch@lst.de> <20200730000544.GC1236929@ZenIV.linux.org.uk> <20200730070329.GB18653@lst.de> <20200730150826.GA1236603@ZenIV.linux.org.uk> <20200730152046.GA21192@lst.de> <20200730161701.GB1236603@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200730161701.GB1236603@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 30, 2020 at 05:17:01PM +0100, Al Viro wrote: > On Thu, Jul 30, 2020 at 05:20:46PM +0200, Christoph Hellwig wrote: > > > Fortunately I think the fix is pretty easy - remove the special pipe > > zero copy optimization from copy_page_to_iter, and just have the > > callers actually want it because they have pagecache or similar > > refcountable pages use it explicitly for the ITER_PIPE case. That gives > > us a safe default with an opt-in into the optimized variant. I'm > > currently auditing all the users of for how it is used and that looks > > pretty promising. > > Huh? What does that have to do with anything? FWIW, none of the dubious (and outright broken) cases I've found go anywhere near that. And it definitely won't help tun/tap...