Message ID | 20230331160914.1608208-42-dhowells@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp690870vqo; Fri, 31 Mar 2023 09:34:08 -0700 (PDT) X-Google-Smtp-Source: AKy350bfag8M/2kBeYbvTC9NHSM/SsDiNgEi+RtdxZdcclgHU1Ky9lncXejs60gsThzF/F1QzPUy X-Received: by 2002:a17:90b:38c5:b0:23d:3f32:1cd5 with SMTP id nn5-20020a17090b38c500b0023d3f321cd5mr29738507pjb.26.1680280448236; Fri, 31 Mar 2023 09:34:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680280448; cv=none; d=google.com; s=arc-20160816; b=T3lKUWLWaIkCGBt7hQusfE0F8pxMBL3P70/w5AzWDw7y/wVXCQeV5SxPjKue6eGTUt UeBAqUFfqe47iDS8YHgTzSN0iCzPoyVo7axu0/7tbGNEXkr3wdV9+24kHDszTfDuShWV 6cFZYrn+6GxbwSRYmW3EqR7N3v3OgjFoacctbY/ULuObEY6nf+X5E5wcv58nS6YtC4yX vjzvSrAG3XmFLZLmsDz87WKx1k7Cb1rFkLI7JrZ3JZN6DvdIOM2tEMLJXMofy2aj2c7v h654d6xswrpHVJzrHPNRFfwMEg6lp/Zi21y8U6qc4YOIxxOwNQ+Z5EcAMRKoC39qEZSN F/TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=0V0VYuNRGUsctVySLnEH8GinGQ4l5nQcc0Sx6Q5aq0A=; b=Yp6VpcYqcycKg1LZAAr6qJpVBaHPIpw7GUFuNTK7GvK3HE27OWMxHPu0gTixFIFTVj FlS0WO9EUH/Bs+0QcrNjSuYskq44BSFUUciQaVh2CXHO7nsh3Ef9JNZMism7JwfQwrJa jz3HT7B4SUq8aI/EeOWMsJNgtNmtXWQO2AgjfWc5MonvZiyOI8gYgEaKPIYrswu2wGwf aa0x82bVEaAWeEvMhyGstHz4ge+hsKtsQN/hhEDW4hIv2QaPzg2Bu800ZpVVQPBEOHYQ 59T41znnIihNSDQCorfAxHtdwzMEqseG8XADOpX1segwBuTT4WNBwVGZ8ei4OOyYqp7y haoQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BT6zI+kr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z19-20020a63e113000000b00513234112b3si2743380pgh.895.2023.03.31.09.33.55; Fri, 31 Mar 2023 09:34:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BT6zI+kr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231905AbjCaQZZ (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Fri, 31 Mar 2023 12:25:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231429AbjCaQYg (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 31 Mar 2023 12:24:36 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DC98236AC for <linux-kernel@vger.kernel.org>; Fri, 31 Mar 2023 09:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680279451; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0V0VYuNRGUsctVySLnEH8GinGQ4l5nQcc0Sx6Q5aq0A=; b=BT6zI+krlRfHBKWZr92YUDhKk7lsqDlEC+JZ/0PRUluCkYjAYjEJ1y0V9uzEaXFIh4AYCp F4tQBKg/HJ4naBElISDM96BJ1xCHPOGxlZABb6YvXFCjREaxl3G5P0Uhpk5FJDF9+5JQNs 0MLs72OiglXhJ1tHGGiIPBREyaz4AXg= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-335-JJSK7rSYNzmbFtG3J_VYoA-1; Fri, 31 Mar 2023 12:11:15 -0400 X-MC-Unique: JJSK7rSYNzmbFtG3J_VYoA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6C1CF29ABA1F; Fri, 31 Mar 2023 16:11:14 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.18]) by smtp.corp.redhat.com (Postfix) with ESMTP id 42ABB40B3EDB; Fri, 31 Mar 2023 16:11:12 +0000 (UTC) From: David Howells <dhowells@redhat.com> To: Matthew Wilcox <willy@infradead.org>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com> Cc: David Howells <dhowells@redhat.com>, Al Viro <viro@zeniv.linux.org.uk>, Christoph Hellwig <hch@infradead.org>, Jens Axboe <axboe@kernel.dk>, Jeff Layton <jlayton@kernel.org>, Christian Brauner <brauner@kernel.org>, Chuck Lever III <chuck.lever@oracle.com>, Linus Torvalds <torvalds@linux-foundation.org>, netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, "Martin K. Petersen" <martin.petersen@oracle.com>, linux-scsi@vger.kernel.org, target-devel@vger.kernel.org Subject: [PATCH v3 41/55] iscsi: Assume "sendpage" is okay in iscsi_tcp_segment_map() Date: Fri, 31 Mar 2023 17:09:00 +0100 Message-Id: <20230331160914.1608208-42-dhowells@redhat.com> In-Reply-To: <20230331160914.1608208-1-dhowells@redhat.com> References: <20230331160914.1608208-1-dhowells@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761901751464310373?= X-GMAIL-MSGID: =?utf-8?q?1761901751464310373?= |
Series |
splice, net: Replace sendpage with sendmsg(MSG_SPLICE_PAGES)
|
|
Commit Message
David Howells
March 31, 2023, 4:09 p.m. UTC
As iscsi is now using sendmsg() with MSG_SPLICE_PAGES rather than sendpage,
assume that sendpage_ok() will return true in iscsi_tcp_segment_map() and
leave it to TCP to copy the data if not.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: "Martin K. Petersen" <martin.petersen@oracle.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Eric Dumazet <edumazet@google.com>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Jens Axboe <axboe@kernel.dk>
cc: Matthew Wilcox <willy@infradead.org>
cc: linux-scsi@vger.kernel.org
cc: target-devel@vger.kernel.org
cc: netdev@vger.kernel.org
---
drivers/scsi/libiscsi_tcp.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
Comments
On venerdì 31 marzo 2023 18:09:00 CEST David Howells wrote: > As iscsi is now using sendmsg() with MSG_SPLICE_PAGES rather than sendpage, > assume that sendpage_ok() will return true in iscsi_tcp_segment_map() and > leave it to TCP to copy the data if not. > > Signed-off-by: David Howells <dhowells@redhat.com> > cc: "Martin K. Petersen" <martin.petersen@oracle.com> > cc: "David S. Miller" <davem@davemloft.net> > cc: Eric Dumazet <edumazet@google.com> > cc: Jakub Kicinski <kuba@kernel.org> > cc: Paolo Abeni <pabeni@redhat.com> > cc: Jens Axboe <axboe@kernel.dk> > cc: Matthew Wilcox <willy@infradead.org> > cc: linux-scsi@vger.kernel.org > cc: target-devel@vger.kernel.org > cc: netdev@vger.kernel.org > --- > drivers/scsi/libiscsi_tcp.c | 13 +++---------- > 1 file changed, 3 insertions(+), 10 deletions(-) > > diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c > index c182aa83f2c9..07ba0d864820 100644 > --- a/drivers/scsi/libiscsi_tcp.c > +++ b/drivers/scsi/libiscsi_tcp.c > @@ -128,18 +128,11 @@ static void iscsi_tcp_segment_map(struct iscsi_segment > *segment, int recv) * coalescing neighboring slab objects into a single frag > which > * triggers one of hardened usercopy checks. > */ > - if (!recv && sendpage_ok(sg_page(sg))) > + if (!recv) > return; > > - if (recv) { > - segment->atomic_mapped = true; > - segment->sg_mapped = kmap_atomic(sg_page(sg)); > - } else { > - segment->atomic_mapped = false; > - /* the xmit path can sleep with the page mapped so use kmap */ > - segment->sg_mapped = kmap(sg_page(sg)); > - } > - > + segment->atomic_mapped = true; > + segment->sg_mapped = kmap_atomic(sg_page(sg)); As you probably know, kmap_atomic() is deprecated. I must admit that I'm not an expert of this code, however, it looks like the mapping has no need to rely on the side effects of kmap_atomic() (i.e., pagefault_disable() and preempt_disable() - but I'm not entirely sure about the possibility that preemption should be explicitly disabled along with the replacement with kmap_local_page()). Last year I've been working on several conversions from kmap{,_atomic}() to kmap_local_page(), however I'm still not sure to understand what's happening here... Am I missing any important details? Can you please explain why we still need that kmap_atomic() instead of kmap_local_page()? Thanks in advance, Fabio > segment->data = segment->sg_mapped + sg->offset + segment- >sg_offset; > }
Fabio M. De Francesco <fmdefrancesco@gmail.com> wrote: > > - if (recv) { > > - segment->atomic_mapped = true; > > - segment->sg_mapped = kmap_atomic(sg_page(sg)); > > - } else { > > - segment->atomic_mapped = false; > > - /* the xmit path can sleep with the page mapped so use > kmap */ > > - segment->sg_mapped = kmap(sg_page(sg)); > > - } > > - > > + segment->atomic_mapped = true; > > + segment->sg_mapped = kmap_atomic(sg_page(sg)); > > As you probably know, kmap_atomic() is deprecated. > > I must admit that I'm not an expert of this code, however, it looks like the > mapping has no need to rely on the side effects of kmap_atomic() (i.e., > pagefault_disable() and preempt_disable() - but I'm not entirely sure about > the possibility that preemption should be explicitly disabled along with the > replacement with kmap_local_page()). > > Last year I've been working on several conversions from kmap{,_atomic}() to > kmap_local_page(), however I'm still not sure to understand what's happening > here... > > Am I missing any important details? Can you please explain why we still need > that kmap_atomic() instead of kmap_local_page()? Actually, it might be worth dropping segment->sg_mapped and segment->data and only doing the kmap_local when necessary. And this: struct msghdr msg = { .msg_flags = flags }; struct kvec iov = { .iov_base = segment->data + offset, .iov_len = copy }; r = kernel_sendmsg(sk, &msg, &iov, 1, copy); should really be using struct bvec, not struct kvec - then the mapping isn't necessary. It looks like this might be the only place the mapping is used, but I'm not 100% certain. David
On martedì 25 aprile 2023 10:30:30 CEST David Howells wrote: > Fabio M. De Francesco <fmdefrancesco@gmail.com> wrote: > > > - if (recv) { > > > - segment->atomic_mapped = true; > > > - segment->sg_mapped = kmap_atomic(sg_page(sg)); > > > - } else { > > > - segment->atomic_mapped = false; > > > - /* the xmit path can sleep with the page mapped so use > > > > kmap */ > > > > > - segment->sg_mapped = kmap(sg_page(sg)); > > > - } > > > - > > > + segment->atomic_mapped = true; > > > + segment->sg_mapped = kmap_atomic(sg_page(sg)); > > > > As you probably know, kmap_atomic() is deprecated. > > > > I must admit that I'm not an expert of this code, however, it looks like the > > mapping has no need to rely on the side effects of kmap_atomic() (i.e., > > pagefault_disable() and preempt_disable() - but I'm not entirely sure about > > the possibility that preemption should be explicitly disabled along with the > > replacement with kmap_local_page()). > > > > Last year I've been working on several conversions from kmap{,_atomic}() to > > kmap_local_page(), however I'm still not sure to understand what's happening > > here... > > > > Am I missing any important details? Can you please explain why we still need > > that kmap_atomic() instead of kmap_local_page()? > > Actually, it might be worth dropping segment->sg_mapped and segment->data and > only doing the kmap_local when necessary. > > And this: > > struct msghdr msg = { .msg_flags = flags }; > struct kvec iov = { > .iov_base = segment->data + offset, > .iov_len = copy > }; > > r = kernel_sendmsg(sk, &msg, &iov, 1, copy); > > should really be using struct bvec, not struct kvec - then the mapping isn't > necessary. FWIW, struct bvec looks better suited (despite I have very little knowledge of this code). I assume that you noticed that we also have the unmapping counterpart (iscsi_tcp_segment_unmap()) which should also be addressed accordingly. > It looks like this might be the only place the mapping is used, > but I'm not 100% certain. It seems that kmap_atomic() (as well as kmap(), which you deleted) is only called by iscsi_tcp_segment_map(), which in turn is called only by iscsi_tcp_segment_done(). I can't see any other places where the mapping is used. I hope that this dialogue may help you somehow to choose the best suited way to get rid of that deprecated kmap_atomic(). Thanks for taking time to address questions from newcomers :-) Fabio > > David
diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c index c182aa83f2c9..07ba0d864820 100644 --- a/drivers/scsi/libiscsi_tcp.c +++ b/drivers/scsi/libiscsi_tcp.c @@ -128,18 +128,11 @@ static void iscsi_tcp_segment_map(struct iscsi_segment *segment, int recv) * coalescing neighboring slab objects into a single frag which * triggers one of hardened usercopy checks. */ - if (!recv && sendpage_ok(sg_page(sg))) + if (!recv) return; - if (recv) { - segment->atomic_mapped = true; - segment->sg_mapped = kmap_atomic(sg_page(sg)); - } else { - segment->atomic_mapped = false; - /* the xmit path can sleep with the page mapped so use kmap */ - segment->sg_mapped = kmap(sg_page(sg)); - } - + segment->atomic_mapped = true; + segment->sg_mapped = kmap_atomic(sg_page(sg)); segment->data = segment->sg_mapped + sg->offset + segment->sg_offset; }