All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: linux-mm <linux-mm@kvack.org>,
	jgg@nvidia.com, Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	John Hubbard <jhubbard@nvidia.com>,
	David Hildenbrand <david@redhat.com>
Subject: Re: [PATCH v2] mm/gup.c: Simplify and fix check_and_migrate_movable_pages() return codes
Date: Thu, 04 Aug 2022 10:01:35 +1000	[thread overview]
Message-ID: <87h72s7toh.fsf@nvdebian.thelocal> (raw)
In-Reply-To: <CA+CK2bCxuSs8aDre7B7cr=B1FpD+d1kJL_1uCU1qtNKErpUSSQ@mail.gmail.com>


Pasha Tatashin <pasha.tatashin@soleen.com> writes:

> On Mon, Aug 1, 2022 at 8:32 PM Alistair Popple <apopple@nvidia.com> wrote:
>>
>> When pinning pages with FOLL_LONGTERM check_and_migrate_movable_pages()
>> is called to migrate pages out of zones which should not contain any
>> longterm pinned pages.
>>
>> When migration succeeds all pages will have been unpinned so pinning
>> needs to be retried. This is indicated by returning zero. When all pages
>> are in the correct zone the number of pinned pages is returned.
>>
>> However migration can also fail, in which case pages are unpinned and
>> -ENOMEM is returned. However if the failure was due to not being unable
>> to isolate a page zero is returned. This leads to indefinite looping in
>> __gup_longterm_locked().
>
> Hi Alistair,
>
> During prohibiting pinning movable zone development, there was a
> discussion where we figured that isolation errors should be transient
> [1]. What isolation errors are you seeing that lead to infinite loop?
> Why do they happen?

Thanks for the pointer Pasha. There were reports of qemu running into
the same zero page problem you reported there, see
https://lore.kernel.org/linux-mm/165490039431.944052.12458624139225785964.stgit@omen/

This doesn't directly fix that problem as we need to allow pinning of
the zero page, but it does prevent the infinite loop. I was going to
re-spin this patch to retry instead of instant failure however reading
that thread it seems the infinite loop is desired behaviour. So will
re-spin this to leave that in-place.

 - Alistair

> Pasha
>
> [1] https://lore.kernel.org/linux-mm/20201218104655.GW32193@dhcp22.suse.cz


  reply	other threads:[~2022-08-04  0:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-02  0:30 [PATCH v2] mm/gup.c: Simplify and fix check_and_migrate_movable_pages() return codes Alistair Popple
2022-08-02 13:50 ` Jason Gunthorpe
2022-08-02 21:36 ` Pasha Tatashin
2022-08-04  0:01   ` Alistair Popple [this message]
2022-08-03  0:12 ` Andrew Morton
2022-08-04  0:12   ` Alistair Popple
2022-08-04  7:40     ` David Hildenbrand
2022-08-04  9:57       ` Alistair Popple

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=87h72s7toh.fsf@nvdebian.thelocal \
    --to=apopple@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=pasha.tatashin@soleen.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.