linux-mm.kvack.org archive mirror
 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 11:08:25 -0700	[thread overview]
Message-ID: <YnFvmc+eMoXvLCWf@google.com> (raw)
In-Reply-To: <f271ca5e-c573-1c48-35a7-b59e9f2e122e@redhat.com>

On Tue, May 03, 2022 at 07:27:06PM +0200, David Hildenbrand wrote:
> >> GUP would see MIGRATE_ISOLATE and would reject pinning. The page has to
> >> be migrated, which can fail if the page is temporarily unmovable.
> > 
> > Why is the page temporarily unmovable? The GUP didn't increase the
> > refcount in the case. If it's not migrabtable, that's not a fault
> > from the GUP but someone is already holding the temporal refcount.
> > It's not the scope this patchset would try to solve it.
> 
> You can have other references on the page that turn it temporarily
> unmovable, for example, via FOLL_GET, short-term FOLL_PIN.

Sure. However, user didn't passed the FOLL_LONGTERM. In that case,
the temporal page migration failure was expected.
What we want to guarantee for successful page migration is only
FOLL_LONGTERM.

If you are talking about the general problem(any GUP API without
FOLL_LONGTERM flag which is supposed to be short-term could turn
into long-term pinning by several reasons - I had struggled with
those issues - FOLL_LONGTERM is misnormer to me), yeah, I agree
we need to fix it but it's orthgonal issue.

> 
> > 
> >>
> >> See my point? We will try migrating in cases where we don't have to
> > 
> > Still not clear for me what you are concerning.
> > 
> >> migrate. I think what we would want to do is always reject pinning a CMA
> >> page, independent of the isolation status. but we don't have that
> > 
> > Always reject pinning a CMA page if it is *FOLL_LONGTERM*
> 
> Yes.
> 
> > 
> >> information available.
> > 
> > page && (MIGRATE_CMA | MIGRATE_ISOLATE) && gup_flags is not enough
> > for it?
> > 
> >>
> >> I raised in the past that we should look into preserving the migration
> >> type and turning MIGRATE_ISOLATE essentially into an additional flag.
> >>
> >>
> >> So I guess this patch is the right thing to do for now, but I wanted to
> >> spell out the implications.
> > 
> > I want but still don't understand what you want to write further
> > about the implication parts. If you make more clear, I am happy to
> > include it.
> 
> What I am essentially saying is that when rejecting to long-term
> FOLL_PIN something that is MIGRATE_ISOLATE now, we might now end up
> having to migrate pages that are actually fine to get pinned, because
> they are not actual CMA pages. And any such migration might fail when
> pages are temporarily unmovable.

Now I understand concern. Then how about introducing cma areas list
and use it instead of migrate type in is_pinnable_page

struct cma  {
  ..
  ..
  list_head list
};

bool is_cma_page(unsigned long pfn) {
    for cma in cma_list
      if (pfn >= cma->base_pfn && pfn < cma->base_pfn + count
        return true;

    return false;
}

Do you want to fix it at this moment or just write down the
possibility in the description and then we could fix once it
really happens later?

> 
> 
> > 
> >>
> >>>
> >>> A thing to get some attention is whether we need READ_ONCE or not
> >>> for the local variable mt.
> >>>
> >>
> >> Hmm good point. Staring at __get_pfnblock_flags_mask(), I don't think
> >> there is anything stopping the compiler from re-reading the value. But
> >> we don't care if we're reading MIGRATE_CMA or MIGRATE_ISOLATE, not
> >> something in between.
> > 
> > How about this?
> > 
> >      CPU A                                                      CPU B
> > 
> > is_pinnable_page
> >   ..
> >   ..                                                set_pageblock_migratetype(MIGRATE_ISOLATE)
> >   mt == MIGRATE_CMA
> >     get_pageblock_miratetype(page)
> >         returns MIGRATE_ISOLATE
> >   mt == MIGRATE_ISOLATE                             set_pageblock_migratetype(MIGRATE_CMA)
> >     get_pageblock_miratetype(page)
> >         returns MIGRATE_CMA
> >  
> > So both conditions fails to detect it.
> 
> I think you're right. That's nasty.

Ccing Paul to borrow expertise. :)

int mt = get_pageblock_migratetype(page);

if (mt == MIGRATE_CMA)
  return true;

if (mt == MIGRATE_ISOLATE)
  return true;

I'd like to keep use the local variable mt's value in folloing
conditions checks instead of refetching the value from
get_pageblock_migratetype.

What's the right way to achieve it?

Thanks in advance!


  reply	other threads:[~2022-05-03 18:08 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
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 [this message]
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=YnFvmc+eMoXvLCWf@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 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).