linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Christoph Hellwig <hch@infradead.org>, <john.hubbard@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Anna Schumaker <anna.schumaker@netapp.com>,
	"David S . Miller" <davem@davemloft.net>,
	Dominique Martinet <asmadeus@codewreck.org>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	Jason Gunthorpe <jgg@ziepe.ca>, Jason Wang <jasowang@redhat.com>,
	Jens Axboe <axboe@kernel.dk>, Latchesar Ionkov <lucho@ionkov.net>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Trond Myklebust <trond.myklebust@hammerspace.com>,
	Christoph Hellwig <hch@lst.de>,
	Matthew Wilcox <willy@infradead.org>, <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>, <ceph-devel@vger.kernel.org>,
	<kvm@vger.kernel.org>, <linux-block@vger.kernel.org>,
	<linux-cifs@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<linux-nfs@vger.kernel.org>, <linux-rdma@vger.kernel.org>,
	<netdev@vger.kernel.org>, <samba-technical@lists.samba.org>,
	<v9fs-developer@lists.sourceforge.net>,
	<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH 00/12] block/bio, fs: convert put_page() to put_user_page*()
Date: Wed, 24 Jul 2019 16:23:21 -0700	[thread overview]
Message-ID: <17f12f3d-981e-a717-c8e5-bfbbfb7ec1a3@nvidia.com> (raw)
In-Reply-To: <20190724061750.GA19397@infradead.org>

On 7/23/19 11:17 PM, Christoph Hellwig wrote:
> On Tue, Jul 23, 2019 at 09:25:06PM -0700, john.hubbard@gmail.com wrote:
>> * Store, in the iov_iter, a "came from gup (get_user_pages)" parameter.
>>   Then, use the new iov_iter_get_pages_use_gup() to retrieve it when
>>   it is time to release the pages. That allows choosing between put_page()
>>   and put_user_page*().
>>
>> * Pass in one more piece of information to bio_release_pages: a "from_gup"
>>   parameter. Similar use as above.
>>
>> * Change the block layer, and several file systems, to use
>>   put_user_page*().
> 
> I think we can do this in a simple and better way.  We have 5 ITER_*
> types.  Of those ITER_DISCARD as the name suggests never uses pages, so
> we can skip handling it.  ITER_PIPE is rejected іn the direct I/O path,
> which leaves us with three.
> 
> Out of those ITER_BVEC needs a user page reference, so we want to call

               ^ ITER_IOVEC, I hope. Otherwise I'm hopeless lost. :)

> put_user_page* on it.  ITER_BVEC always already has page reference,
> which means in the block direct I/O path path we alread don't take
> a page reference.  We should extent that handling to all other calls
> of iov_iter_get_pages / iov_iter_get_pages_alloc.  I think we should
> just reject ITER_KVEC for direct I/O as well as we have no users and
> it is rather pointless.  Alternatively if we see a use for it the
> callers should always have a life page reference anyway (or might
> be on kmalloc memory), so we really should not take a reference either.
> 
> In other words:  the only time we should ever have to put a page in
> this patch is when they are user pages.  We'll need to clean up
> various bits of code for that, but that can be done gradually before
> even getting to the actual put_user_pages conversion.
> 

Sounds great. I'm part way into it and it doesn't look too bad. The main
question is where to scatter various checks and assertions, to keep
the kvecs out of direct I/0. Or at least keep the gups away from 
direct I/0.


thanks,
-- 
John Hubbard
NVIDIA

  reply	other threads:[~2019-07-24 23:23 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-24  4:25 [PATCH 00/12] block/bio, fs: convert put_page() to put_user_page*() john.hubbard
2019-07-24  4:25 ` [PATCH 01/12] mm/gup: add make_dirty arg to put_user_pages_dirty_lock() john.hubbard
2019-07-24  4:25 ` [PATCH 02/12] iov_iter: add helper to test if an iter would use GUP v2 john.hubbard
2019-07-24  4:25 ` [PATCH 03/12] block: bio_release_pages: use flags arg instead of bool john.hubbard
2019-07-24  5:30   ` Christoph Hellwig
2019-07-29 20:57     ` Jerome Glisse
2019-07-30 10:25       ` Christoph Hellwig
2019-07-30 15:57         ` Jerome Glisse
2019-08-01  8:20           ` Christoph Hellwig
2019-07-24  4:25 ` [PATCH 04/12] block: bio_release_pages: convert put_page() to put_user_page*() john.hubbard
2019-07-24  4:25 ` [PATCH 05/12] block_dev: " john.hubbard
2019-07-24  4:25 ` [PATCH 06/12] fs/nfs: " john.hubbard
2019-07-24  4:25 ` [PATCH 07/12] vhost-scsi: " john.hubbard
2019-07-24  4:34   ` John Hubbard
2019-07-24  8:07   ` Michael S. Tsirkin
2019-07-24  4:25 ` [PATCH 08/12] fs/cifs: " john.hubbard
2019-07-24  4:25 ` [PATCH 09/12] fs/fuse: " john.hubbard
2019-07-24  4:25 ` [PATCH 10/12] fs/ceph: " john.hubbard
2019-07-24  4:25 ` [PATCH 11/12] 9p/net: " john.hubbard
2019-07-24  4:25 ` [PATCH 12/12] fs/ceph: fix a build warning: returning a value from void function john.hubbard
2019-07-24  6:17 ` [PATCH 00/12] block/bio, fs: convert put_page() to put_user_page*() Christoph Hellwig
2019-07-24 23:23   ` John Hubbard [this message]
2019-08-05 22:54   ` John Hubbard
2019-08-07  6:34     ` Christoph Hellwig
2019-08-07  6:38       ` John Hubbard
2019-07-25  0:41 ` Bob Liu
2019-07-26  1:24   ` John Hubbard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17f12f3d-981e-a717-c8e5-bfbbfb7ec1a3@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=anna.schumaker@netapp.com \
    --cc=asmadeus@codewreck.org \
    --cc=axboe@kernel.dk \
    --cc=ceph-devel@vger.kernel.org \
    --cc=davem@davemloft.net \
    --cc=ericvh@gmail.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=jasowang@redhat.com \
    --cc=jgg@ziepe.ca \
    --cc=john.hubbard@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=miklos@szeredi.hu \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=samba-technical@lists.samba.org \
    --cc=trond.myklebust@hammerspace.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    --cc=viro@zeniv.linux.org.uk \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).