From: Christoph Hellwig <hch@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: Matthew Wilcox <willy@infradead.org>,
David Howells <dhowells@redhat.com>,
John Hubbard <jhubbard@nvidia.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Christoph Hellwig <hch@infradead.org>,
Jens Axboe <axboe@kernel.dk>, Jeff Layton <jlayton@kernel.org>,
Logan Gunthorpe <logang@deltatee.com>,
linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 0/8] iov_iter: Improve page extraction (ref, pin or just list)
Date: Tue, 24 Jan 2023 05:21:28 -0800 [thread overview]
Message-ID: <Y8/bWF6s8oPJdNRs@infradead.org> (raw)
In-Reply-To: <20230124102931.g7e33syuhfo7s36h@quack3>
On Tue, Jan 24, 2023 at 11:29:31AM +0100, Jan Kara wrote:
> True but as John said sometimes we need to writeout even pinned page - e.g.
> on fsync(2). For some RDMA users which keep pages pinned for days or
> months, this is actually crutial...
I think we have to distinguish between short term (just FOLL_PIN)
and long term (FOLL_PIN | FOLL_LONGERM) pins.
For short term ones the proper thing to do in data integrity writeback
is to simply wait for the unpin. For the long term pins that obviously
can't work. The right answer for that is complicated and I don't have
a good answer yet. The best one would probably to probibit them on
MAP_SHARED file backed mappings - this might break some existing
software, but that software is already so broken that this might be
best.
next prev parent reply other threads:[~2023-01-24 13:21 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 17:55 [PATCH v7 0/8] iov_iter: Improve page extraction (ref, pin or just list) David Howells
2023-01-20 17:55 ` [PATCH v7 1/8] iov_iter: Define flags to qualify page extraction David Howells
2023-01-21 13:01 ` Christoph Hellwig
2023-01-20 17:55 ` [PATCH v7 2/8] iov_iter: Add a function to extract a page list from an iterator David Howells
2023-01-21 13:01 ` Christoph Hellwig
2023-01-21 13:10 ` Christoph Hellwig
2023-01-21 13:30 ` David Howells
2023-01-21 13:33 ` Christoph Hellwig
2023-01-23 11:28 ` David Hildenbrand
2023-01-23 11:51 ` David Howells
2023-01-23 13:11 ` David Hildenbrand
2023-01-23 13:19 ` David Howells
2023-01-23 13:24 ` David Hildenbrand
2023-01-23 19:56 ` John Hubbard
2023-01-26 22:15 ` Al Viro
2023-01-26 23:41 ` David Hildenbrand
2023-01-27 0:05 ` David Howells
2023-01-27 0:20 ` David Hildenbrand
2023-01-23 13:38 ` David Howells
2023-01-23 14:20 ` David Hildenbrand
2023-01-23 14:48 ` Christoph Hellwig
2023-01-23 16:11 ` Jan Kara
2023-01-23 16:17 ` Christoph Hellwig
2023-01-23 23:07 ` John Hubbard
2023-01-24 5:57 ` Christoph Hellwig
2023-01-24 6:55 ` John Hubbard
2023-01-23 12:00 ` David Howells
2023-01-20 17:55 ` [PATCH v7 3/8] mm: Provide a helper to drop a pin/ref on a page David Howells
2023-01-20 17:55 ` [PATCH v7 4/8] block: Rename BIO_NO_PAGE_REF to BIO_PAGE_REFFED and invert the meaning David Howells
2023-01-21 13:04 ` Christoph Hellwig
2023-01-23 9:38 ` David Howells
2023-01-23 9:56 ` Christoph Hellwig
2023-01-20 17:55 ` [PATCH v7 5/8] block: Add BIO_PAGE_PINNED David Howells
2023-01-21 13:05 ` Christoph Hellwig
2023-01-20 17:55 ` [PATCH v7 6/8] block: Make bio structs pin pages rather than ref'ing if appropriate David Howells
2023-01-21 13:07 ` Christoph Hellwig
2023-01-23 11:28 ` David Howells
2023-01-23 14:49 ` Christoph Hellwig
2023-01-20 17:55 ` [PATCH v7 7/8] block: Fix bio_flagged() so that gcc can better optimise it David Howells
2023-01-20 17:55 ` [PATCH v7 8/8] mm: Renumber FOLL_GET and FOLL_PIN down David Howells
2023-01-20 18:59 ` Matthew Wilcox
2023-01-20 19:18 ` David Howells
2023-01-23 16:31 ` [PATCH v7 0/8] iov_iter: Improve page extraction (ref, pin or just list) Matthew Wilcox
2023-01-23 16:42 ` Jan Kara
2023-01-23 17:33 ` Matthew Wilcox
2023-01-23 22:53 ` John Hubbard
2023-01-24 10:29 ` Jan Kara
2023-01-24 13:21 ` Christoph Hellwig [this message]
2023-01-23 16:38 ` David Howells
2023-01-23 16:42 ` Matthew Wilcox
2023-01-23 17:25 ` Jan Kara
2023-01-24 10:24 ` David Hildenbrand
2023-01-23 17:19 ` David Howells
2023-01-23 18:04 ` Matthew Wilcox
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=Y8/bWF6s8oPJdNRs@infradead.org \
--to=hch@infradead.org \
--cc=axboe@kernel.dk \
--cc=dhowells@redhat.com \
--cc=jack@suse.cz \
--cc=jhubbard@nvidia.com \
--cc=jlayton@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=viro@zeniv.linux.org.uk \
--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).