All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Miaohe Lin <linmiaohe@huawei.com>, Matthew Wilcox <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>, Yu Zhao <yuzhao@google.com>,
	<akpm@linux-foundation.org>, <hannes@cmpxchg.org>,
	<vbabka@suse.cz>, <axboe@kernel.dk>, <iamjoonsoo.kim@lge.com>,
	<alexs@kernel.org>, <apopple@nvidia.com>, <minchan@kernel.org>,
	<david@redhat.com>, <shli@fb.com>, <hillf.zj@alibaba-inc.com>,
	<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/5] mm/vmscan: put the redirtied MADV_FREE pages back to anonymous LRU list
Date: Thu, 15 Jul 2021 17:01:45 -0700	[thread overview]
Message-ID: <a20a937e-da73-0aea-0373-36f01b3a6425@nvidia.com> (raw)
In-Reply-To: <0634e9d6-9fcc-e65f-dc5e-bed13004b8fe@huawei.com>

On 7/15/21 4:30 AM, Miaohe Lin wrote:
...
>>>> So, it seems lockless GUP can redirty the MADV_FREE page. But is it ok to just release
>>>> a redirtied MADV_FREE pages? Because we hold the last reference here and the page will
>>>> be freed anyway...
>>>
>>> I don't see how lockless GUP can redirty the page.  It can grab the
>>> refcount, thus making the refcount here two.  Then the call to freeze
>>> here fails and the page stays on the list.  But the lockless GUP checks
>>> the page is still in the page table (and discovers it isn't, so releases
>>> the reference count).  Am I missing a path that lets lockless GUP dirty
>>> the page?
>>>
>>
>> If a device driver pins some pages using gup, and the device then uses dma
>> to write to those pages, then you could get there. That story is part of the
>> reasoning that led to creating pin_user_pages(), which btw does not yet
>> fully solve that case.
> 
> Many thanks for your explanation.
> So the similar scenario that is clarified in the __remove_mapping() is possible:

I probably should have added that the scenario I was describing is broken even
before any patches that you might apply here. I was just trying to ensure that
the complete list of scenarios was known.



thanks,
-- 
John Hubbard
NVIDIA

  reply	other threads:[~2021-07-16  0:01 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-10 10:03 [PATCH 0/5] Cleanup and fixup for vmscan Miaohe Lin
2021-07-10 10:03 ` [PATCH 1/5] mm/vmscan: put the redirtied MADV_FREE pages back to anonymous LRU list Miaohe Lin
2021-07-10 23:22   ` Yu Zhao
2021-07-10 23:22     ` Yu Zhao
2021-07-12  7:11     ` Miaohe Lin
2021-07-13  7:25       ` Yu Zhao
2021-07-13  7:25         ` Yu Zhao
2021-07-13 13:16         ` Miaohe Lin
2021-07-12  7:22   ` Michal Hocko
2021-07-12 11:03     ` Miaohe Lin
2021-07-13  9:30       ` Michal Hocko
2021-07-13 13:13         ` Miaohe Lin
2021-07-13 13:34           ` Matthew Wilcox
2021-07-14 11:36             ` Miaohe Lin
2021-07-14 11:48               ` Matthew Wilcox
2021-07-14 19:43                 ` John Hubbard
2021-07-15 11:30                   ` Miaohe Lin
2021-07-16  0:01                     ` John Hubbard [this message]
2021-07-16  1:53                       ` Miaohe Lin
2021-07-10 10:03 ` [PATCH 2/5] mm/vmscan: remove misleading setting to sc->priority Miaohe Lin
2021-07-12  7:24   ` Michal Hocko
2021-07-12 11:10     ` Miaohe Lin
2021-07-10 10:03 ` [PATCH 3/5] mm/vmscan: remove unneeded return value of kswapd_run() Miaohe Lin
2021-07-12  7:25   ` Michal Hocko
2021-07-10 10:03 ` [PATCH 4/5] mm/vmscan: add 'else' to remove check_pending label Miaohe Lin
2021-07-12  7:26   ` Michal Hocko
2021-07-10 10:03 ` [PATCH 5/5] mm/vmscan: fix misleading comment in isolate_lru_pages() Miaohe Lin
2021-07-12  7:28   ` Michal Hocko
2021-07-12 11:16     ` Miaohe Lin
2021-07-13  9:32       ` Michal Hocko
2021-07-13 12:50         ` Miaohe Lin

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=a20a937e-da73-0aea-0373-36f01b3a6425@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexs@kernel.org \
    --cc=apopple@nvidia.com \
    --cc=axboe@kernel.dk \
    --cc=david@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=hillf.zj@alibaba-inc.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=shli@fb.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=yuzhao@google.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.