From: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: John Hubbard <jhubbard@nvidia.com>,
Jason Gunthorpe <jgg@nvidia.com>,
linux-kernel@vger.kernel.org,
Andrea Arcangeli <aarcange@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@lst.de>, Hugh Dickins <hughd@google.com>,
Jann Horn <jannh@google.com>,
Kirill Shutemov <kirill@shutemov.name>,
Kirill Tkhai <ktkhai@virtuozzo.com>,
Linux-MM <linux-mm@kvack.org>, Michal Hocko <mhocko@suse.com>,
Oleg Nesterov <oleg@redhat.com>, Peter Xu <peterx@redhat.com>
Subject: Re: [PATCH 1/2] mm: reorganize internal_get_user_pages_fast()
Date: Tue, 27 Oct 2020 10:55:45 +0100 [thread overview]
Message-ID: <20201027095545.GA30382@lst.de> (raw)
In-Reply-To: <20201027093301.GA16090@quack2.suse.cz>
On Tue, Oct 27, 2020 at 10:33:01AM +0100, Jan Kara wrote:
> Actually there are callers that care about partial success. See e.g.
> iov_iter_get_pages() usage in fs/direct_io.c:dio_refill_pages() or
> bio_iov_iter_get_pages(). These places handle partial success just fine and
> not allowing partial success from GUP could regress things...
But most users do indeed not care. Maybe an explicit FOLL_PARTIAL to
opt into partial handling could clean up a lot of the mess. Maybe just
for pin_user_pages for now.
next prev parent reply other threads:[~2020-10-27 9:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-24 0:19 [PATCH 0/2] Add a 'seqcount' between gup_fast and copy_page_range Jason Gunthorpe
2020-10-24 0:19 ` [PATCH 1/2] mm: reorganize internal_get_user_pages_fast() Jason Gunthorpe
2020-10-24 4:44 ` John Hubbard
2020-10-26 23:59 ` Jason Gunthorpe
2020-10-27 9:33 ` Jan Kara
2020-10-27 9:55 ` Christoph Hellwig [this message]
2020-10-28 6:00 ` John Hubbard
2020-10-27 13:15 ` Jason Gunthorpe
2020-10-28 6:00 ` John Hubbard
2020-10-28 6:05 ` John Hubbard
2020-10-24 0:19 ` [PATCH 2/2] mm: prevent gup_fast from racing with COW during fork Jason Gunthorpe
2020-10-24 5:19 ` John Hubbard
2020-10-24 5:31 ` John Hubbard
2020-10-26 23:49 ` Jason Gunthorpe
2020-10-27 0:14 ` Linus Torvalds
2020-10-27 11:32 ` Jason Gunthorpe
2020-10-27 0:35 ` John Hubbard
2020-10-27 7:32 ` John Hubbard
2020-11-02 3:25 ` [mm] e498078ae9: will-it-scale.per_thread_ops -1.4% regression kernel test robot
2020-10-24 5:14 ` [PATCH 0/2] Add a 'seqcount' between gup_fast and copy_page_range 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=20201027095545.GA30382@lst.de \
--to=hch@lst.de \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=kirill@shutemov.name \
--cc=ktkhai@virtuozzo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=oleg@redhat.com \
--cc=peterx@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.