[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YyxzBPZRp/uulRmf@ZenIV>
Date: Thu, 22 Sep 2022 15:36:52 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Christoph Hellwig <hch@...radead.org>
Cc: Jan Kara <jack@...e.cz>, John Hubbard <jhubbard@...dia.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jens Axboe <axboe@...nel.dk>,
Miklos Szeredi <miklos@...redi.hu>,
"Darrick J . Wong" <djwong@...nel.org>,
Trond Myklebust <trond.myklebust@...merspace.com>,
Anna Schumaker <anna@...nel.org>,
David Hildenbrand <david@...hat.com>,
Logan Gunthorpe <logang@...tatee.com>,
linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-xfs@...r.kernel.org, linux-nfs@...r.kernel.org,
linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 4/7] iov_iter: new iov_iter_pin_pages*() routines
On Thu, Sep 22, 2022 at 07:31:36AM -0700, Christoph Hellwig wrote:
> On Wed, Sep 14, 2022 at 04:51:17AM +0100, Al Viro wrote:
> > Unless I'm misreading Jan, the question is whether they should get or
> > pin.
>
> And I think the answer is: inside ->read_iter or ->write_iter they
> should neither get or pin. The callers of it need to pin the pages
> if they are pagecache pages that can potentially be written to through
> shared mappings, else a get would be enough. But the method instance
> should not have to care and just be able to rely on the caller making
> sure they do not go away.
The interesting part, AFAICS, is where do we _unpin_ them and how do
we keep track which pages (obtained from iov_iter_get_pages et.al.)
need to be unpinned.
> > I'm really tempted to slap
> > if (WARN_ON(i->data_source))
> > return 0;
> > into copy_to_iter() et.al., along with its opposite for copy_from_iter().
>
> Ys, I think that would be useful. And we could use something more
> descriptive than READ/WRITE to start with.
See #work.iov_iter; done, but it took a bit of fixing the places that
create iov_iter instances.
Powered by blists - more mailing lists