All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: David Hildenbrand <david@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	John Hubbard <jhubbard@nvidia.com>,
	John Dias <joaodias@google.com>
Subject: Re: [PATCH] mm: fix is_pinnable_page against on cma page
Date: Tue, 3 May 2022 08:26:42 -0700	[thread overview]
Message-ID: <YnFJss0doXGCmq3w@google.com> (raw)
In-Reply-To: <08e9855c-395d-f40c-de3d-1ec8b644bfe8@redhat.com>

On Tue, May 03, 2022 at 03:15:24AM +0200, David Hildenbrand wrote:
> 
> >>>> However, I assume we have the same issue right now already with
> >> ZONE_MOVABLE and MIGRATE_CMA when trying to pin a page residing on these
> > 
> > ZONE_MOVALBE is also changed dynamically?
> > 
> 
> Sorry, with "same issue" I meant failing to pin if having to migrate and
> the page is temporarily unmovable.
> 
> >> there are temporarily unmovable and we fail to migrate. But it would now
> >> apply even without ZONE_MOVABLE or MIGRATE_CMA. Hm...
> > 
> > Didn't parse your last mention.
> 
> On a system that neither uses ZONE_MOVABLE nor MIGRATE_CMA we might have
> to migrate now when pinning.

I don't understand your point. My problem is pin_user_pages with
FOLL_LONGTERM. It shouldn't pin a page from ZONE_MOVABLE and cma area
without migrating page out of movable zone or CMA area.
That's why try_grab_folio checks whether target page stays in those
movable areas. However, to check CMA area, is_migrate_cma_page is
racy so the FOLL_LONGTERM flag semantic is broken right now.

Do you see any problem of the fix?

A thing to get some attention is whether we need READ_ONCE or not
for the local variable mt.

  reply	other threads:[~2022-05-03 15:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-02 17:35 [PATCH] mm: fix is_pinnable_page against on cma page Minchan Kim
2022-05-02 18:02 ` David Hildenbrand
2022-05-02 18:22   ` Minchan Kim
2022-05-03  1:15     ` David Hildenbrand
2022-05-03 15:26       ` Minchan Kim [this message]
2022-05-03 16:02         ` David Hildenbrand
2022-05-03 17:20           ` Minchan Kim
2022-05-03 17:27             ` David Hildenbrand
2022-05-03 18:08               ` Minchan Kim
2022-05-03 18:12                 ` Minchan Kim
2022-05-04 22:48           ` Minchan Kim
2022-05-05  6:48             ` Minchan Kim
2022-05-05 17:00               ` Mike Kravetz
2022-05-05 17:25                 ` Peter Xu
2022-05-08  0:31                   ` David Hildenbrand
2022-05-05 17:27                 ` Minchan Kim
2022-05-08  0:28               ` David Hildenbrand
2022-05-02 19:15 ` kernel test robot
2022-05-02 21:10 ` kernel test robot
2022-05-03  8:48 ` kernel test robot

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=YnFJss0doXGCmq3w@google.com \
    --to=minchan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=jhubbard@nvidia.com \
    --cc=joaodias@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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.