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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98998C77B7A for ; Wed, 24 May 2023 13:21:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D498F900006; Wed, 24 May 2023 09:21:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF881900002; Wed, 24 May 2023 09:21:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE6FD900006; Wed, 24 May 2023 09:21:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B000E900002 for ; Wed, 24 May 2023 09:21:53 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D517240986 for ; Wed, 24 May 2023 13:21:50 +0000 (UTC) X-FDA: 80825211180.22.BBA8BA6 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 6C57CA000A for ; Wed, 24 May 2023 13:21:47 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=RCJYyCM2; spf=pass (imf15.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684934507; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zd0OFfNiZ9y269Uix6ptp+k9hpY/9UM79H7Ki9EesyY=; b=QtqkPoFGR/7cxNWcGtuf2KhvbfzIhYgeKufiTTzaQtYG/6CXWGEA8sn/mUO3XhSSsgifF3 5iqNORhToqpojD3WAMUZawNsVBxqN3CMPfLgA23vQh+obabAIH6vqc92TSw3LopWbv1i7i APly9wL1FAlE972NgJwmMx5ulguEtCw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684934507; a=rsa-sha256; cv=none; b=CwWqAJgM3sa+ZD7ZbyT2QKKs8E3QILAelKT6ky1lYCB+5M7b6E1zcgqDfO5LcsdGZ/xo8C o1ENVMcP61XjPeYCdIHs1gblby/VYQk/qfcmqvZ9QeJuTUfpAQMwyi2hAAIUj7Nl5DtkTC c7OuSdOmvEaXe0CJZR8m0ej23ju1WJY= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=RCJYyCM2; spf=pass (imf15.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684934506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zd0OFfNiZ9y269Uix6ptp+k9hpY/9UM79H7Ki9EesyY=; b=RCJYyCM258UqE76UelmIjSVgiLxQX/gYlLKjKvMjfnLSHvEJYdZXPVdu+A7t4I+Ms4rAd/ q0LPOK0Stq4KE/C257VvnK0kyDR8Nz651y40QDxAvN0Eitzt5x8+FaXVNKsbYRZqRHKtfM KicHXxpJnMJ4syXGtMsPeDg77Bi3LBs= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-221-p0cb3Y9GNjKJiZIUxGFWzw-1; Wed, 24 May 2023 09:21:40 -0400 X-MC-Unique: p0cb3Y9GNjKJiZIUxGFWzw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6B37085A5AA; Wed, 24 May 2023 13:21:38 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.39.192.68]) by smtp.corp.redhat.com (Postfix) with ESMTP id E9ED140C6EC4; Wed, 24 May 2023 13:21:34 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <82041a42-e7b0-bde3-0f70-8ad180565794@huawei.com> References: <82041a42-e7b0-bde3-0f70-8ad180565794@huawei.com> <20230522121125.2595254-1-dhowells@redhat.com> <20230522121125.2595254-4-dhowells@redhat.com> To: Yunsheng Lin Cc: dhowells@redhat.com, netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Willem de Bruijn , David Ahern , Matthew Wilcox , Al Viro , Christoph Hellwig , Jens Axboe , Jeff Layton , Christian Brauner , Chuck Lever III , Linus Torvalds , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH net-next v10 03/16] net: Add a function to splice pages into an skbuff for MSG_SPLICE_PAGES MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3587227.1684934494.1@warthog.procyon.org.uk> Date: Wed, 24 May 2023 14:21:34 +0100 Message-ID: <3587228.1684934494@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Stat-Signature: op7wz8e5ut5ge56tjhcgoqif3nxi9hs7 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 6C57CA000A X-Rspam-User: X-HE-Tag: 1684934507-19072 X-HE-Meta: U2FsdGVkX1/LBcfL7C69VWD88dKJLtsj0aVLjOP1q1UG5T7iNIosZfJzkteLAsR8ZfGfOAi+Sr2Ux1vX4hvk3KpmefigTQYeqaSvpB2qhYkXMTFxHC3mggY61E8CVoCQeJjq+qP6EdW13o6akyn3477oEm0t5BWCyX79z3Eofsu2xPTxgG0HYVxW0k4dhc7glSct2src4eq+H8gaKHD0nEUZ8/hVoS4gEDZ7uQ7mLBmwDvi9IxofQexrVElZI3ibc3ZzZpwKmxdGrvXnedeffRRFv046ForSuMxQY/6SJzPjnIUEm4Mqew40a1Rpe2bWuvqjlSN7GT6f7QmBLp67uoVcJQg1gQGZM6jTLrS3rYeOOHSN8D2Ev+wv52WSjhO5nuzElD05MDg66h1Yug1dgCJ8J4SxYOXJn4tYX8kOgLR1NgacnSJx74uALC86DOyNdLr8XdzNh4BLNjyADQ1qcaENaIGxNGqqjPckyUBBsPBPqzuFe6zXXIb9WjRcxJ91hucowSF7MZZbjSU+duFI070BIaDxw3LpJxuM08o+gXb9Dy1ToQ84SV0Mx3AacgNZZ0+TEWh6vrNRYaUFw/hyY3r+ZX6/phQhYgaGXdQh+FgGrkLrIQ+uMNCMdhIe4X15JyvJjXxztLf9Tm0Zi2csA/l7oCXC0hw9qHAouwIi+cYmG8N88kUJO4shd7o+h2UHPvv0KAD+LyYJLCfJ3BWcWPu9rPMQZaISqPKv79XQowJZ+Ij4ozXDNadEK/LPA+FiOvJjlR8vZKC0QwByq8tnVVxPUlcJa3iu3m1Ba3adY720A+YOG7RguVHgySf9n70gM0IpHj2clihFcGzDwwgiXyfkfqKULATjQFrOJcyFn87CSavRxTkQfQyaIwYBmrJ5k0hmErqA42gV4BLr0MXsoDhr+S1cZcn0zF4lAWz0Lp2xIGOLKc+CJ6cHY69QwRwJpLNVDcW4VFFUNXdyfLC Nu0X8CCM PNQsICoy5iqjxXN51NQO5rBGE9zA7ZVDBbkQcZL6cEgidJADvhu+sQ6KLco9dLxCjIvDlYhy5gcg9CnMefOCEHaGC00mUErr8vrZe/79RF/1t8J/soWNuDx6+upfuskFQFmqw/weZUjHU2xDJrcNxKqeYuMTpPYi5omp7EdocegLKpjph3pK/1xJCR86bCBRDlLRwYqnFEltkYmpeLplhkn/DOqcFpEX3O7Yzcr5zKJiUKjeuJZFEL3U/7JBsMyLpGWwh6kehSkQhLk+fSzMGj0HDQ4C4JZlPfYfIi3KXN8xSp9g= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Yunsheng Lin wrote: > > + * Returns the amount of data spliced/copied or -EMSGSIZE if there's > > I am not seeing any copying done directly in the skb_splice_from_iter(), > maybe iov_iter_extract_pages() has done copying for it? Ah, I took the code for that out and deferred it. The comment needs amending. > > + ret = skb_append_pagefrags(skb, page, off, part, > > + frag_limit); > > + if (ret < 0) { > > + iov_iter_revert(iter, len); > > I am not sure I understand the error handling here, doesn't 'len' > indicate the remaining size of the data to be appended to skb, Yes. > maybe we should revert the size of data that is already appended to skb > here? Does 'spliced' need to be adjusted accordingly? Neither. > I am not very familiar with the 'struct iov_iter' yet An iov_iter struct is a cursor over a buffer. It advances as we draw data or space from that buffer. Sometimes we overdraw and have to back up a bit - hence the revert function. It could possibly be renamed to something more appropriate as (if/when ITER_PIPE is removed) it doesn't actually change the buffer. So looking at skb_splice_from_iter(): iov_iter_extract_pages() is used to get a list of pages from the buffer that we think we're going to be able to handle. If the buffer is of type IOVEC or UBUF those pages would have pins inserted into them also; otherwise no pin or ref will be taken on them. MSG_SPLICE_PAGES should not be used with IOVEC or UBUF types for the moment as the network layer does not yet handle pins. iov_iter_extract_pages() will advance the iterator past the page fragments it has returned. If skb_append_pagefrags() indicates that it could not attach the page, this isn't necessarily fatal - it could return -EMSGSIZE to indicate there was no space, in which case we return to the caller to create a new skbuff. If a non-fatal error occurs, we may already have committed some parts of the buffer to the skbuff and rewinding into that part of the buffer would cause a repeat of the data which would be bad. What the iov_iter_revert() is doing is rewinding iterator back past the part of the extracted pages that we didn't get to use so that we will pick up where we left off next time we're called. It does *not* and must not revert the data we've already transferred. Arguably, I should revert when I return -EIO because sendpage_ok() returned false, but that's a fatal error. David