Message ID | 20230214171330.2722188-6-dhowells@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp3100177wrn; Tue, 14 Feb 2023 09:16:52 -0800 (PST) X-Google-Smtp-Source: AK7set87OL7VDVuSuSEUCUiwx0h3Dvgvwub+HxQDeVbTGN2u2SqYcw8tg1aRZ7AMYSBqutjUHzSd X-Received: by 2002:a17:902:f950:b0:19a:98c9:8cea with SMTP id kx16-20020a170902f95000b0019a98c98ceamr3084737plb.39.1676395012088; Tue, 14 Feb 2023 09:16:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676395012; cv=none; d=google.com; s=arc-20160816; b=fALa9BpIhe8kWLTLV2qEP6sCKihxL6Ad61z/pmXeR6RSIfmz05rgoY8VAgTxE5e98E uTgPyWHRAMWwLaNR+VpZU0qn245LJRIkQYQfo569Y9uNl8VWZkBcafYQE+5APUyAb1qa ox1S0qXoHthvOSSPawyIXJzhqqmBD3ypscYSp7wfCQ/UWKh0B2PbX7zavReQHrxo2ALR lHOCEKwazWkHQUP0kWAA1lPj0FiMD/Fp5ZrPCtMAFUPWEIt1Vtw7LJkEM6yvLwvOMeSW rOxDaHgBr2mWY0m14GFbNoRr0IrstjE02kn+mhkMVyp9luGikGvadn9QTytvrDWpuFiK BV6Q== 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=LVjIujk8d1N0k6RGniY3UP+0o4vFHY30HdwwNIbIhak=; b=OYtI6vmyfNpp0zKTzFwPL3ds1zzYEubFqFJR9Am+tJEJkSB0T+3ZPgBN9bIb+zkmKq Mzn1AsnsJDD7P7Yn/eBQjsuuBd+YnyZrC6kOucR4hle1YcP9F/JekcEZVO/Fa0FvzCIa hFfGKJ8ONqIxMdcvcGApIxHIJqrjbKnDDLI4BEzs2jDTcOiLcpyJ/q8A2KhZIsE1CxZ8 Ukgb30XRRRMtDX7WHhVl89uKRBesefezPVMYOU9xPn0rB5vyFphDmZNNuTaLPvWAe+pM hG/pof9SkOW6Yoc8azXy75JnBcHM00eAa0BVJefx4Xn+Sol/YfjX/hCtB35o7J27z250 wKzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=MA2Tp0y4; 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 w7-20020a63af07000000b004dfe85e60f8si14773143pge.321.2023.02.14.09.16.39; Tue, 14 Feb 2023 09:16:52 -0800 (PST) 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=MA2Tp0y4; 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 S232437AbjBNRPT (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Tue, 14 Feb 2023 12:15:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232822AbjBNROw (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Feb 2023 12:14:52 -0500 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 A044F5266 for <linux-kernel@vger.kernel.org>; Tue, 14 Feb 2023 09:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676394843; 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=LVjIujk8d1N0k6RGniY3UP+0o4vFHY30HdwwNIbIhak=; b=MA2Tp0y4F6kIgwUR6MJz0HS9ffds8A1m3jEaav9Jj+wqi2zJd/v719q2TeR3tm8nKY50Ut HhvvM/2V3IkPs0zUVv4+Q17Ev0X1hJefoF8cCFLzO4MOKRShGH59LtNBlRTErsH8ZlBdCA e/X3QsjeoH7S1U0rjAZD9p+SOljZF9A= 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-608-VwTllVNdOty5IfHcJbDwmw-1; Tue, 14 Feb 2023 12:14:00 -0500 X-MC-Unique: VwTllVNdOty5IfHcJbDwmw-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 4BBF285CCE0; Tue, 14 Feb 2023 17:13:59 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.33.36.24]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0784C40C10FA; Tue, 14 Feb 2023 17:13:46 +0000 (UTC) From: David Howells <dhowells@redhat.com> To: Jens Axboe <axboe@kernel.dk>, Al Viro <viro@zeniv.linux.org.uk>, Christoph Hellwig <hch@infradead.org> Cc: David Howells <dhowells@redhat.com>, Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>, Jeff Layton <jlayton@kernel.org>, David Hildenbrand <david@redhat.com>, Jason Gunthorpe <jgg@nvidia.com>, Logan Gunthorpe <logang@deltatee.com>, Hillf Danton <hdanton@sina.com>, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Christoph Hellwig <hch@lst.de>, John Hubbard <jhubbard@nvidia.com>, Miklos Szeredi <miklos@szeredi.hu>, linux-unionfs@vger.kernel.org Subject: [PATCH v14 05/17] overlayfs: Implement splice-read Date: Tue, 14 Feb 2023 17:13:18 +0000 Message-Id: <20230214171330.2722188-6-dhowells@redhat.com> In-Reply-To: <20230214171330.2722188-1-dhowells@redhat.com> References: <20230214171330.2722188-1-dhowells@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 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 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?1757827576035949768?= X-GMAIL-MSGID: =?utf-8?q?1757827576035949768?= |
Series |
iov_iter: Improve page extraction (pin or just list)
|
|
Commit Message
David Howells
Feb. 14, 2023, 5:13 p.m. UTC
Implement splice-read for overlayfs by passing the request down a layer
rather than going through generic_file_splice_read() which is going to be
changed to assume that ->read_folio() is present on buffered files.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Christoph Hellwig <hch@lst.de>
cc: Jens Axboe <axboe@kernel.dk>
cc: Al Viro <viro@zeniv.linux.org.uk>
cc: John Hubbard <jhubbard@nvidia.com>
cc: David Hildenbrand <david@redhat.com>
cc: Matthew Wilcox <willy@infradead.org>
cc: Miklos Szeredi <miklos@szeredi.hu>
cc: linux-unionfs@vger.kernel.org
cc: linux-block@vger.kernel.org
cc: linux-fsdevel@vger.kernel.org
cc: linux-mm@kvack.org
---
fs/overlayfs/file.c | 36 +++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
Comments
On Tue, 14 Feb 2023 at 18:14, David Howells <dhowells@redhat.com> wrote: > > Implement splice-read for overlayfs by passing the request down a layer > rather than going through generic_file_splice_read() which is going to be > changed to assume that ->read_folio() is present on buffered files. > > Signed-off-by: David Howells <dhowells@redhat.com> > cc: Christoph Hellwig <hch@lst.de> > cc: Jens Axboe <axboe@kernel.dk> > cc: Al Viro <viro@zeniv.linux.org.uk> > cc: John Hubbard <jhubbard@nvidia.com> > cc: David Hildenbrand <david@redhat.com> > cc: Matthew Wilcox <willy@infradead.org> > cc: Miklos Szeredi <miklos@szeredi.hu> > cc: linux-unionfs@vger.kernel.org > cc: linux-block@vger.kernel.org > cc: linux-fsdevel@vger.kernel.org > cc: linux-mm@kvack.org > --- > fs/overlayfs/file.c | 36 +++++++++++++++++++++++++++++++++++- > 1 file changed, 35 insertions(+), 1 deletion(-) > > diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c > index c9d0c362c7ef..267b61df6fcd 100644 > --- a/fs/overlayfs/file.c > +++ b/fs/overlayfs/file.c > @@ -419,6 +419,40 @@ static ssize_t ovl_write_iter(struct kiocb *iocb, struct iov_iter *iter) > return ret; > } > > +static ssize_t ovl_splice_read(struct file *in, loff_t *ppos, > + struct pipe_inode_info *pipe, size_t len, > + unsigned int flags) > +{ > + const struct cred *old_cred; > + struct fd real; > + ssize_t ret; > + > + ret = ovl_real_fdget(in, &real); > + if (ret) > + return ret; > + > + ret = -EINVAL; > + if (in->f_flags & O_DIRECT && > + !(real.file->f_mode & FMODE_CAN_ODIRECT)) > + goto out_fdput; This is unnecessary, as it was already done in ovl_real_fdget() -> ovl_real_fdget_meta() -> ovl_change_flags(). > + if (!real.file->f_op->splice_read) > + goto out_fdput; > + > + ret = rw_verify_area(READ, in, ppos, len); Should be on real.file. > + if (unlikely(ret < 0)) > + return ret; Leaks fd. > + > + old_cred = ovl_override_creds(file_inode(in)->i_sb); > + ret = real.file->f_op->splice_read(real.file, ppos, pipe, len, flags); > + > + revert_creds(old_cred); > + ovl_file_accessed(in); > +out_fdput: > + fdput(real); > + > + return ret; > +} > + > /* > * Calling iter_file_splice_write() directly from overlay's f_op may deadlock > * due to lock order inversion between pipe->mutex in iter_file_splice_write() > @@ -695,7 +729,7 @@ const struct file_operations ovl_file_operations = { > .fallocate = ovl_fallocate, > .fadvise = ovl_fadvise, > .flush = ovl_flush, > - .splice_read = generic_file_splice_read, > + .splice_read = ovl_splice_read, > .splice_write = ovl_splice_write, > > .copy_file_range = ovl_copy_file_range, >
Miklos Szeredi <miklos@szeredi.hu> wrote: > > + ret = -EINVAL; > > + if (in->f_flags & O_DIRECT && > > + !(real.file->f_mode & FMODE_CAN_ODIRECT)) > > + goto out_fdput; > > This is unnecessary, as it was already done in ovl_real_fdget() -> > ovl_real_fdget_meta() -> ovl_change_flags(). Does that mean ovl_read_iter() and ovl_write_iter() shouldn't be doing it, then? David
On Wed, 15 Feb 2023 at 16:04, David Howells <dhowells@redhat.com> wrote: > > Miklos Szeredi <miklos@szeredi.hu> wrote: > > > > + ret = -EINVAL; > > > + if (in->f_flags & O_DIRECT && > > > + !(real.file->f_mode & FMODE_CAN_ODIRECT)) > > > + goto out_fdput; > > > > This is unnecessary, as it was already done in ovl_real_fdget() -> > > ovl_real_fdget_meta() -> ovl_change_flags(). > > Does that mean ovl_read_iter() and ovl_write_iter() shouldn't be doing it, > then? That's a different thing, because ovl_*_iter() are checking on ki->flags, not f_flags. Thanks, Miklos
diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c index c9d0c362c7ef..267b61df6fcd 100644 --- a/fs/overlayfs/file.c +++ b/fs/overlayfs/file.c @@ -419,6 +419,40 @@ static ssize_t ovl_write_iter(struct kiocb *iocb, struct iov_iter *iter) return ret; } +static ssize_t ovl_splice_read(struct file *in, loff_t *ppos, + struct pipe_inode_info *pipe, size_t len, + unsigned int flags) +{ + const struct cred *old_cred; + struct fd real; + ssize_t ret; + + ret = ovl_real_fdget(in, &real); + if (ret) + return ret; + + ret = -EINVAL; + if (in->f_flags & O_DIRECT && + !(real.file->f_mode & FMODE_CAN_ODIRECT)) + goto out_fdput; + if (!real.file->f_op->splice_read) + goto out_fdput; + + ret = rw_verify_area(READ, in, ppos, len); + if (unlikely(ret < 0)) + return ret; + + old_cred = ovl_override_creds(file_inode(in)->i_sb); + ret = real.file->f_op->splice_read(real.file, ppos, pipe, len, flags); + + revert_creds(old_cred); + ovl_file_accessed(in); +out_fdput: + fdput(real); + + return ret; +} + /* * Calling iter_file_splice_write() directly from overlay's f_op may deadlock * due to lock order inversion between pipe->mutex in iter_file_splice_write() @@ -695,7 +729,7 @@ const struct file_operations ovl_file_operations = { .fallocate = ovl_fallocate, .fadvise = ovl_fadvise, .flush = ovl_flush, - .splice_read = generic_file_splice_read, + .splice_read = ovl_splice_read, .splice_write = ovl_splice_write, .copy_file_range = ovl_copy_file_range,