From: Alistair Popple <apopple@nvidia.com>
To: David Hildenbrand <david@redhat.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
Alex Williamson <alex.williamson@redhat.com>,
akpm@linux-foundation.org, minchan@kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
paulmck@kernel.org, jhubbard@nvidia.com, joaodias@google.com
Subject: Re: [PATCH] mm: Re-allow pinning of zero pfns
Date: Fri, 29 Jul 2022 12:49:00 +1000 [thread overview]
Message-ID: <87zggstyto.fsf@nvdebian.thelocal> (raw)
In-Reply-To: <6492e852-8acf-95a9-a3a0-8ce8bbaf46d6@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 28.07.22 10:45, Alistair Popple wrote:
>>
>> Looks like the original patch might need rebasing. I am about to post a
>> clean-up for the tortured logic in check_and_migrate_movable_pages() so
>> can incorporate it there, but I'm wondering what the consensus was for
>> pinning of zero pfn?
>
> We have to keep it working right now, but in most cases (inside
> MAP_PRIVATE regions) it's shaky and undesired.
Ok. Well I've looked at this now so may as well stick
Reviewed-by: Alistair Popple <apopple@nvidia.com>
on it. However I think it needs rebasing, should I send an updated
version?
>>
>> Currently my clean-up will result in PUP returning an error for the zero
>> pfn rather than looping indefinitely in the kernel. However it wasn't
>> clear from this thread if returning an error is ok, or if R/O pinning
>> of the zero pfn should succeed?
>
> I'm working on proper COW breaking in MAP_PRIVATE mappings, which will,
> for example, unshare the shared zeropage and properly replace it by
> exclusive anon pages first in the FOLL_LONGTERM case.
prev parent reply other threads:[~2022-07-29 2:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-10 22:35 [PATCH] mm: Re-allow pinning of zero pfns Alex Williamson
2022-06-11 0:21 ` Minchan Kim
2022-06-11 18:29 ` David Hildenbrand
2022-06-15 15:56 ` Jason Gunthorpe
2022-06-23 18:07 ` David Hildenbrand
2022-06-23 20:21 ` Alex Williamson
2022-06-23 20:47 ` Jason Gunthorpe
2022-06-24 0:11 ` Alistair Popple
2022-06-24 1:34 ` Jason Gunthorpe
2022-06-24 1:55 ` Alistair Popple
2022-07-28 8:45 ` Alistair Popple
2022-07-28 9:23 ` David Hildenbrand
2022-07-29 2:49 ` Alistair Popple [this message]
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=87zggstyto.fsf@nvdebian.thelocal \
--to=apopple@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=david@redhat.com \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=joaodias@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=paulmck@kernel.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 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.