Re: [PATCH v2] mm: fix race between MADV_FREE reclaim and blkdev direct IO read

From: John Hubbard <jhubbard@nvidia.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Yu Zhao <yuzhao@google.com>,
	Mauricio Faria de Oliveira <mfo@canonical.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-block@vger.kernel.org,
	Huang Ying <ying.huang@intel.com>,
	Miaohe Lin <linmiaohe@huawei.com>, Yang Shi <shy828301@gmail.com>
Subject: Re: [PATCH v2] mm: fix race between MADV_FREE reclaim and blkdev direct IO read
Date: Tue, 11 Jan 2022 15:38:24 -0800	[thread overview]
Message-ID: <7094dbd6-de0c-9909-e657-e358e14dc6c3@nvidia.com> (raw)
In-Reply-To: <Yd39019io71DHbVq@google.com>

On 1/11/22 13:59, Minchan Kim wrote:
...
>>>> Marking pages dirty after pinning them is a pre-existing area of
>>>> problems. See the long-running LWN articles about get_user_pages() [1].
>>>
>>> Oh, Do you mean marking page dirty in DIO path is already problems?
>>
>>                    ^ marking page dirty too late in DIO path
>>
>> Typo fix.
> 
> I looked though the articles but couldn't find dots to connetct
> issues with this MADV_FREE issue. However, man page shows a clue

The area covered in those articles is about the fact that file system
and block are not safely interacting with pinned memory. Even today.
So I'm trying to make sure you're aware of that before you go too far
in that direction.

> why it's fine.
> 
> ```
>         O_DIRECT  I/Os should never be run concurrently with the fork(2) system call, if the memory buffer is a private map‐
>         ping (i.e., any mapping created with the mmap(2) MAP_PRIVATE flag; this includes memory allocated on  the  heap  and
>         statically  allocated  buffers).  Any such I/Os, whether submitted via an asynchronous I/O interface or from another
>         thread in the process, should be completed before fork(2) is called.  Failure to do so can result in data corruption
>         and  undefined  behavior  in parent and child processes.
> 
> ```
> 
> I think it would make the copy_present_pte's page_dup_rmap safe.

I'd have to see this in patch form, because I'm not quite able to visualize it yet.

thanks,
-- 
John Hubbard
NVIDIA