Message ID | 1770755.1681894451@warthog.procyon.org.uk |
---|---|
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 b10csp227820vqo; Wed, 19 Apr 2023 01:57:25 -0700 (PDT) X-Google-Smtp-Source: AKy350Zw9G8MFR8lGSXojKCdqqbfzabiNROLFEjYZD5tDcF5KjVmODY+GBtwe9HOZhI+pE92zIqR X-Received: by 2002:a05:6a20:4282:b0:ee:bac2:c6e1 with SMTP id o2-20020a056a20428200b000eebac2c6e1mr3512386pzj.23.1681894645315; Wed, 19 Apr 2023 01:57:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681894645; cv=none; d=google.com; s=arc-20160816; b=q300C1TNr6phiazNL/Ww4wn7TW2w7Bj3kr5qJtCohAVtrWMftUcrfwR5reUmBsr67R Ghqr6PYhCRqJTSLVbHKYikjIOu7c9lNlr9LLoqlFXNQqZEqRTLFM2YmCDebyUTF+V9He VsUZpebuqdAlkeOA9L0EY6NsaDvKxh/ORaq0kGuQbIL2mm66PX1hdqTE0yMjl8k+Ab2F +Ylyz4ff6XIuwwu8pHAlq4qyDCp0JN7DQgnlXiXfhSWaXP8ejklvHRZLZz9b4QG1Kczz xxwB2u4fb6cllTYh+q5NKKpIhxQnFZb4NKcvbeytGYOPFC+jhUYfwBLUwojq4776nntn bXZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:content-transfer-encoding :content-id:mime-version:subject:cc:to:from:organization :dkim-signature; bh=J099iEeGas8X+c0Ugwu2YYwSR8o/a4NF1OsG1hAhZcc=; b=KPx6kG+dx80GRR5P+4KNd0DKfJDUMYG/a1y1/WiZLr1w22fiNFa7N/FHXGRhN0Ascb seNZrFNxnz9KdGjkf4PjD8EAjdM6Ma19p/cyLKa9WJgWfIdl+//jFGCz9bZSaFDSNTWI Id5H25Ifej6NAmPEoD0kTEYeF7mMbGrOpve18hGBcENj3kJyNqNjNIcpU1Fs6HtrUsGU C4AUe/dWeIo/shl2jQB7Ut1WGBKQLwxGLBcfG0yJSa/tuHcLQbs465yFVdKSp2RAztyw mfHrQLUddRm1HIDphcXskrqTcqKPaQBRTwKPFErMOlpqW6tcBkgA2qwV5bQ8uGjd/cqV /gDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="E1NxjYf/"; 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 o10-20020a656a4a000000b004fb9330dcfcsi16956912pgu.323.2023.04.19.01.57.13; Wed, 19 Apr 2023 01:57:25 -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="E1NxjYf/"; 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 S232813AbjDSIzK (ORCPT <rfc822;peter110.wang@gmail.com> + 99 others); Wed, 19 Apr 2023 04:55:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59858 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232650AbjDSIzE (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Apr 2023 04:55:04 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CFF324C2C for <linux-kernel@vger.kernel.org>; Wed, 19 Apr 2023 01:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681894457; 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: content-transfer-encoding:content-transfer-encoding; bh=J099iEeGas8X+c0Ugwu2YYwSR8o/a4NF1OsG1hAhZcc=; b=E1NxjYf//Dyhe34vdpIDycJkEsXgLmnhsduRP5H+RdrVxE35yRS1qs6AlV5n9FlMQpTEhQ vf4ZyM/SIcMEsz74DD0fUXW9r4ri46WH+9eLUY/Vn6FD5gtk8wTV4gKJ8xUd0/PswStvoe p4YypG+37HREIjMuh8uA6eMEwUpgpb8= 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-538-1ikd473jN-q5I59GX08wYA-1; Wed, 19 Apr 2023 04:54:14 -0400 X-MC-Unique: 1ikd473jN-q5I59GX08wYA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 532FE101A557; Wed, 19 Apr 2023 08:54:13 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.42.28.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id A32BA1121314; Wed, 19 Apr 2023 08:54:11 +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 <dhowells@redhat.com> To: Jens Axboe <axboe@kernel.dk> cc: dhowells@redhat.com, Ayush Jain <ayush.jain3@amd.com>, Christoph Hellwig <hch@lst.de>, Al Viro <viro@zeniv.linux.org.uk>, David Hildenbrand <david@redhat.com>, John Hubbard <jhubbard@nvidia.com>, Steve French <stfrench@microsoft.com>, linux-mm@kvack.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] splice: Fix filemap of a blockdev MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1770754.1681894451.1@warthog.procyon.org.uk> Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Apr 2023 09:54:11 +0100 Message-ID: <1770755.1681894451@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,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,T_SCC_BODY_TEXT_LINE autolearn=ham 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?1763594359744797538?= X-GMAIL-MSGID: =?utf-8?q?1763594359744797538?= |
Series |
splice: Fix filemap of a blockdev
|
|
Commit Message
David Howells
April 19, 2023, 8:54 a.m. UTC
Fix the new filemap_splice_read() function to get i_size from in->f_mapping->host, not in->f_inode so that it works with block devices too (in->f_inode points to the device file, which is typically zero size). Fixes: 07073eb01c5f ("splice: Add a func to do a splice from a buffered file without ITER_PIPE") Link: https://lore.kernel.org/r/0c6b661c-f7ff-cf12-b7f0-00b6b2f1317b@amd.com/ Reported-by: Ayush Jain <ayush.jain3@amd.com> cc: Jens Axboe <axboe@kernel.dk> cc: Christoph Hellwig <hch@lst.de> cc: Al Viro <viro@zeniv.linux.org.uk> cc: David Hildenbrand <david@redhat.com> cc: John Hubbard <jhubbard@nvidia.com> cc: Steve French <stfrench@microsoft.com> cc: linux-mm@kvack.org cc: linux-block@vger.kernel.org cc: linux-fsdevel@vger.kernel.org --- mm/filemap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Comments
Hello David, This resolves the Fio-test issue that i reported in Link: https://lore.kernel.org/r/0c6b661c-f7ff-cf12-b7f0-00b6b2f1317b@amd.com/ On 4/19/2023 2:24 PM, David Howells wrote: > Fix the new filemap_splice_read() function to get i_size from > in->f_mapping->host, not in->f_inode so that it works with block devices > too (in->f_inode points to the device file, which is typically zero size). > > Fixes: 07073eb01c5f ("splice: Add a func to do a splice from a buffered file without ITER_PIPE") > Link: https://lore.kernel.org/r/0c6b661c-f7ff-cf12-b7f0-00b6b2f1317b@amd.com/ > Reported-by: Ayush Jain <ayush.jain3@amd.com> Tested-by: Ayush Jain <ayush.jain3@amd.com> > cc: Jens Axboe <axboe@kernel.dk> > cc: Christoph Hellwig <hch@lst.de> > cc: Al Viro <viro@zeniv.linux.org.uk> > cc: David Hildenbrand <david@redhat.com> > cc: John Hubbard <jhubbard@nvidia.com> > cc: Steve French <stfrench@microsoft.com> > cc: linux-mm@kvack.org > cc: linux-block@vger.kernel.org > cc: linux-fsdevel@vger.kernel.org > --- > mm/filemap.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/filemap.c b/mm/filemap.c > index 470be06b6096..f86cc8acf33a 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -2902,7 +2902,7 @@ ssize_t filemap_splice_read(struct file *in, loff_t *ppos, > do { > cond_resched(); > > - if (*ppos >= i_size_read(file_inode(in))) > + if (*ppos >= i_size_read(in->f_mapping->host)) > break; > > iocb.ki_pos = *ppos; > @@ -2918,7 +2918,7 @@ ssize_t filemap_splice_read(struct file *in, loff_t *ppos, > * part of the page is not copied back to userspace (unless > * another truncate extends the file - this is desired though). > */ > - isize = i_size_read(file_inode(in)); > + isize = i_size_read(in->f_mapping->host); > if (unlikely(*ppos >= isize)) > break; > end_offset = min_t(loff_t, isize, *ppos + len); > Regards, Ayush Jain
On Wed, 19 Apr 2023 09:54:11 +0100, David Howells wrote: > Fix the new filemap_splice_read() function to get i_size from > in->f_mapping->host, not in->f_inode so that it works with block devices > too (in->f_inode points to the device file, which is typically zero size). > > Applied, thanks! [1/1] splice: Fix filemap of a blockdev commit: 5a9515a407d1aec1dd76c24fe99d9981730b74fb Best regards,
Jens Axboe <axboe@kernel.dk> wrote:
> [1/1] splice: Fix filemap of a blockdev
Actually, would you be able to fix the subject? I left a word out:
splice: Fix filemap splice of a blockdev
or maybe:
splice: Fix buffered splice of a blockdev
Sorry about that,
David
Note that this shouldn't affect direct_splice_read() as that doesn't look at the size of the file, but rather just keeps reading from it until the requested amount is read, the pipe is full or ->read_iter() indicates EOF by returning 0 (so it could work for copy-splicing from a pipe/socket/chardev too). David
On 4/19/23 6:57 AM, David Howells wrote: > Jens Axboe <axboe@kernel.dk> wrote: > >> [1/1] splice: Fix filemap of a blockdev > > Actually, would you be able to fix the subject? I left a word out: > > splice: Fix filemap splice of a blockdev > > or maybe: > > splice: Fix buffered splice of a blockdev Fixed it up.
diff --git a/mm/filemap.c b/mm/filemap.c index 470be06b6096..f86cc8acf33a 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2902,7 +2902,7 @@ ssize_t filemap_splice_read(struct file *in, loff_t *ppos, do { cond_resched(); - if (*ppos >= i_size_read(file_inode(in))) + if (*ppos >= i_size_read(in->f_mapping->host)) break; iocb.ki_pos = *ppos; @@ -2918,7 +2918,7 @@ ssize_t filemap_splice_read(struct file *in, loff_t *ppos, * part of the page is not copied back to userspace (unless * another truncate extends the file - this is desired though). */ - isize = i_size_read(file_inode(in)); + isize = i_size_read(in->f_mapping->host); if (unlikely(*ppos >= isize)) break; end_offset = min_t(loff_t, isize, *ppos + len);