linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@intel.com>
To: Yu Zhao <yuzhao@google.com>
Cc: Mauricio Faria de Oliveira <mfo@canonical.com>,
	 Minchan Kim <minchan@kernel.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	 Yang Shi <shy828301@gmail.com>,
	 Miaohe Lin <linmiaohe@huawei.com>,
	linux-mm@kvack.org,  linux-block@vger.kernel.org
Subject: Re: [PATCH v3] mm: fix race between MADV_FREE reclaim and blkdev direct IO read
Date: Thu, 17 Feb 2022 14:08:31 +0800	[thread overview]
Message-ID: <87zgmq6n4w.fsf@yhuang6-desk2.ccr.corp.intel.com> (raw)
In-Reply-To: <Yg1zjHkctX0zkF+o@google.com> (Yu Zhao's message of "Wed, 16 Feb 2022 14:58:36 -0700")

Yu Zhao <yuzhao@google.com> writes:

> On Wed, Feb 16, 2022 at 02:48:19PM +0800, Huang, Ying wrote:
>> Yu Zhao <yuzhao@google.com> writes:
>> 
>> > On Wed, Feb 02, 2022 at 06:27:47PM -0300, Mauricio Faria de Oliveira wrote:
>> >> On Wed, Feb 2, 2022 at 4:56 PM Yu Zhao <yuzhao@google.com> wrote:
>> >> >
>> >> > On Mon, Jan 31, 2022 at 08:02:55PM -0300, Mauricio Faria de Oliveira wrote:
>> >> > > Problem:
>> >> > > =======
>> >> >
>> >> > Thanks for the update. A couple of quick questions:
>> >> >
>> >> > > Userspace might read the zero-page instead of actual data from a
>> >> > > direct IO read on a block device if the buffers have been called
>> >> > > madvise(MADV_FREE) on earlier (this is discussed below) due to a
>> >> > > race between page reclaim on MADV_FREE and blkdev direct IO read.
>> >> >
>> >> > 1) would page migration be affected as well?
>> >> 
>> >> Could you please elaborate on the potential problem you considered?
>> >> 
>> >> I checked migrate_pages() -> try_to_migrate() holds the page lock,
>> >> thus shouldn't race with shrink_page_list() -> with try_to_unmap()
>> >> (where the issue with MADV_FREE is), but maybe I didn't get you
>> >> correctly.
>> >
>> > Could the race exist between DIO and migration? While DIO is writing
>> > to a page, could migration unmap it and copy the data from this page
>> > to a new page?
>> 
>> Check the migrate_pages() code,
>> 
>>   migrate_pages
>>     unmap_and_move
>>       __unmap_and_move
>>         try_to_migrate // set PTE to swap entry with PTL
>>         move_to_new_page
>>           migrate_page
>>             folio_migrate_mapping
>>               folio_ref_count(folio) != expected_count // check page ref count
>>             folio_migrate_copy
>> 
>> The page ref count is checked after unmapping and before copying.  This
>> is good, but it appears that we need a memory barrier between checking
>> page ref count and copying page.
>
> I didn't look into this but, off the top of head, this should be
> similar if not identical to the DIO case. Therefore, it requires two
> barriers -- before and after the refcnt check (which may or may not
> exist).

Yes.  I think so too.

Best Regards,
Huang, Ying


      parent reply	other threads:[~2022-02-17  6:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-31 23:02 [PATCH v3] mm: fix race between MADV_FREE reclaim and blkdev direct IO read Mauricio Faria de Oliveira
2022-01-31 23:43 ` Andrew Morton
2022-02-01  2:23   ` Mauricio Faria de Oliveira
2022-02-02 14:03 ` Christoph Hellwig
2022-02-02 16:29   ` Mauricio Faria de Oliveira
2022-02-02 19:56 ` Yu Zhao
2022-02-02 21:27   ` Mauricio Faria de Oliveira
2022-02-02 21:53     ` Yu Zhao
2022-02-03 22:17       ` Mauricio Faria de Oliveira
2022-02-04  5:56         ` Yu Zhao
2022-02-04  7:03           ` John Hubbard
2022-02-04 18:59             ` Mauricio Faria de Oliveira
2022-02-04 18:58           ` Mauricio Faria de Oliveira
2022-02-16  6:48       ` Huang, Ying
2022-02-16 21:58         ` Yu Zhao
2022-02-16 22:00           ` Yu Zhao
2022-02-17  6:08           ` Huang, Ying [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=87zgmq6n4w.fsf@yhuang6-desk2.ccr.corp.intel.com \
    --to=ying.huang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mfo@canonical.com \
    --cc=minchan@kernel.org \
    --cc=shy828301@gmail.com \
    --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 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).