Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp551123pxa; Fri, 21 Aug 2020 14:17:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzgqX8/CbvUxwC7G0Tq4Z+rww/+tapnoOBv48mNdqbP0gTqLQd7zfP9ByJMSSKoo2jOMBeX X-Received: by 2002:a17:907:7251:: with SMTP id ds17mr4657232ejc.289.1598044656270; Fri, 21 Aug 2020 14:17:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598044656; cv=none; d=google.com; s=arc-20160816; b=Oz5SZK9rgs9YZP0U29ZW9pFkAGitN+q1F/GkZQtAt2GghiFZB+qxYk1pi6BTeAGJAf +PqPTvjXHjTr5vau51O1d2PZhozVsOA/Bw3DhrNBFgIdZR0nx19PdlKvvJIH+kUMMOuu FpG2mnVHjgqjxg5pWf8szJD0bKXXD60SsUoW+5piWdOYgK5Dn2c0v9QaYXc9q4xjqQVr /k++x2wHzwU37QxTD7XHl6mCeAzoG12cc+OKkea3BABMUzrWeItOdlhjawRzAdgeD/69 1b9k3svYoNooYz95RWtGJ0dvti/O2uKGJRxsP9rYg0zA/CnaCR9cpiQFX2S5l0xmgTA8 YgaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=w5JUA4/8/S0obnZTnUBUxrb2kbxAPSLNrJsuBqpgpgg=; b=mnjIAslczN3HwZHsat+O2Ko79uSfFTQO6fpAr7mCNuYaLImg35TL4hzJcKlTG5KZy6 JtzLegZFyc9rhs+XI1oMiq1EMlqO8XpjYw9zi/yZhRO9Z7mtbZk4Ppr25NgkhNc4hsb0 eiy14ApSsE/zWCcHHz6FilXJVtwdSenxUHCuCAuRz9iaSyGe317lTeS6O8nb1IAGtMrc JFdejwjqIAJh2FOillxI45CaJm4EGrTlvQImyMxTbX/rRxMWGm9uBXg2z39fRbhUaPIV g+sydhrzjAdtmNNehETn2eJsWlmEGwn2Ni6m/QF7BzN0ZfosUG3i/P7zAL4UVONvllgh n0og== 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 mf10si1932987ejb.611.2020.08.21.14.17.12; Fri, 21 Aug 2020 14:17:36 -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 S1726752AbgHUVOB (ORCPT + 99 others); Fri, 21 Aug 2020 17:14:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725948AbgHUVOB (ORCPT ); Fri, 21 Aug 2020 17:14:01 -0400 Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D146C061573; Fri, 21 Aug 2020 14:14:01 -0700 (PDT) Received: from localhost (unknown [IPv6:2601:601:9f00:477::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id BFB02128A448B; Fri, 21 Aug 2020 13:57:14 -0700 (PDT) Date: Fri, 21 Aug 2020 14:14:00 -0700 (PDT) Message-Id: <20200821.141400.594703865403700191.davem@davemloft.net> To: hch@lst.de Cc: kuba@kernel.org, colyli@suse.de, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net: bypass ->sendpage for slab pages From: David Miller In-Reply-To: <20200820043744.GA4349@lst.de> References: <20200819051945.1797088-1-hch@lst.de> <20200819.120709.1311664171016372891.davem@davemloft.net> <20200820043744.GA4349@lst.de> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 21 Aug 2020 13:57:14 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Christoph Hellwig Date: Thu, 20 Aug 2020 06:37:44 +0200 > If you look at who uses sendpage outside the networking layer itself > you see that it is basically block driver and file systems. These > have no way to control what memory they get passed and have to deal > with everything someone throws at them. I see nvme doing virt_to_page() on several things when it calls into kernel_sendpage(). This is the kind of stuff I want cleaned up, and which your patch will not trap nor address. In nvme it sometimes seems to check for sendpage validity: /* can't zcopy slab pages */ if (unlikely(PageSlab(page))) { ret = sock_no_sendpage(queue->sock, page, offset, len, flags); } else { ret = kernel_sendpage(queue->sock, page, offset, len, flags); } Yet elsewhere does not and just blindly calls: ret = kernel_sendpage(queue->sock, virt_to_page(pdu), offset_in_page(pdu) + req->offset, len, flags); This pdu seems to come from a page frag allocation. That's the target side. On the host side: ret = kernel_sendpage(cmd->queue->sock, page, cmd->offset, left, flags); No page slab check or anything like that. I'm hesitent to put in the kernel_sendpage() patch, becuase it provides a disincentive to fix up code like this.