Received-SPF: pass (google.com: domain of linux-kernel+bounces-161135-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <328b2b69-e4ab-4a00-9137-1f7c3dc2d195@nvidia.com>
Date: Sat, 27 Apr 2024 12:11:18 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] mm: Fix race between __split_huge_pmd_locked() and
 GUP-fast
To: Zi Yan <ziy@nvidia.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>,
 Andrew Morton <akpm@linux-foundation.org>, Zi Yan <zi.yan@cs.rutgers.edu>,
 "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>, linux-mm@kvack.org,
 linux-kernel@vger.kernel.org
References: <20240425170704.3379492-1-ryan.roberts@arm.com>
 <17956e0f-1101-42d7-9cba-87e196312484@nvidia.com>
 <2C9D897B-0E96-42F0-B3C4-9926E6DF5F4B@nvidia.com>
Content-Language: en-US
From: John Hubbard <jhubbard@nvidia.com>
In-Reply-To: <2C9D897B-0E96-42F0-B3C4-9926E6DF5F4B@nvidia.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?ZllOc0hlMnJqTTRLV0p0WkJVWVB2ZzE3YXhpMXVJYU9FVEZTQk5EdlB6bVlI?=
 =?utf-8?B?STAwWVU2QU40bmRrTGYwWGh2TjB6Q25KVVJhRzBqL2Z5S1ROUUhzM0ZFMlRW?=
 =?utf-8?B?R25peFlSSkl0NEFwZnEvSk4zUzl1aEdCSE02UjFOK1VYa1FYZ09mT1pXUHRJ?=
 =?utf-8?B?R3hPdUFOamUxMTBkVURnT0V6TVU1Zm1DNzVOWnJjOEVoUnpxYzdtSmZmQU50?=
 =?utf-8?B?N2l4THlrYTE3eWl4WHRLOXcxc29wSElBSFB0N1RWOHdqSlBxcFAvVGJ2VTht?=
 =?utf-8?B?YVB4VmpqVnk0dmM4Y3BZejIrdnJNenVIZDJoK2RvOVNNTlFaUTBsZjMyY3d5?=
 =?utf-8?B?eCtmMVQ3Mm5lVTYrekowb1dZS1lIOVpETWxmY0gwOUFmSWdTS2d1VjMzSEkv?=
 =?utf-8?B?SUJLT20zRkRHck52dkF6TTBXNFc0L1FtUFI3VVhNRXcvSHd0OVdUS0VqcGF1?=
 =?utf-8?B?Nm5vTzdoMTE5UFkzRkRrNzNHYUlrbEM2MnpISEd5WFZCUXNjUFByeVVIcGxz?=
 =?utf-8?B?YUg3bUgzaFR1OWlxWksvODh1NVFCUkM1bzkzK1VtcXpmV0pGbkdWZ2NYUkd6?=
 =?utf-8?B?clc1b3dpZk5PWHRleEwvVTAwKzNxbVZWTDc1SXdLWnV5WDhpTmNubEdvZEZB?=
 =?utf-8?B?THZTV0VGOEI0ME1xQ3AvY2VrdzJBcmFpbGIvZFlxaWQ4ZFZaZmZ6S095L1N2?=
 =?utf-8?B?MWFXWHBTRjZhWTNlOEZqUW9ZQTBHY2ZOcXpuWlM3Z1RuK1d2SHB1cy9vS0Fr?=
 =?utf-8?B?QTJvN01Xbm0vc2xUVm1sT2cxdVBMeTdVUm1rMVc0L1RRbW9YaFkyYnIyVC9D?=
 =?utf-8?B?OWNwcy9OV1diVkROakFOWDZ0N0NROWNKUFgxWTdvY1Myc1liMzc2RTd0T0gw?=
 =?utf-8?B?S29WVnFOUUM0by8zeXdHWnFMV1E4eFc1dFkyTmZ3dGV0ODc5Qjc3QU8vaFMr?=
 =?utf-8?B?aENDNE95SldSWVo1N1NSazhxcTJqNDNzcGJRc2dZYUMxVXJxSlhvelJ1ektS?=
 =?utf-8?B?SVRFckZIcVZEdm5hSkRWaFhSYkRTV1FOT010eWpheVJmNEdRcExNelF5ZEVx?=
 =?utf-8?B?emxqaStEZEVFdmVvZmhOZGhOOVlrZUloeStHdnlDVTN4NDkvK1FmTzJpU1ZY?=
 =?utf-8?B?aUJlUXpQSWxXU3BxN3poWmhOM1AxcDVUUU9NUGJydy82blVyakFzM3c2VXNx?=
 =?utf-8?B?RVNwZkVNUnhLWFhJb2RLRktvQ1N5bTVHcTlSTU95aW1FRzNBS2xmYnNKZzZO?=
 =?utf-8?B?bVptSlllcXRhQ3dNcUsrcE16RlIwYnkvOVAvK25ibzJ1YzFOZHFpSUxNRktm?=
 =?utf-8?B?bUJrekwzaFFUcXozQWxyanNYOFcwNm54Q1dQa3R6ejdLWDZQTktMaks0dkJ5?=
 =?utf-8?B?ellEU3FvZVUyZWZ5Ui82bHIyQ2lHOVRwVXFCcG40WmFIZHdVSG1tZEhOYkx6?=
 =?utf-8?B?cWJSUFE3cDYwZzBKcHI3eWkxUURvQVNaWDZHUWRJR25oRi8yQVJibWRENDdV?=
 =?utf-8?B?UzRQNHc3a091aHgvMVF4azgwRkduYUZGWjFHMGFoWVNBMmFXVkY2VWFSQ0hU?=
 =?utf-8?B?MElLcFp2QngvbFBycHJHZDhxMEpvWmRuSnAxaFVad29wUUpvYnMrUFU1SEUy?=
 =?utf-8?B?VU4yZUQzYnE3bWVNZlRITzZoZXViY3Ftcy8zNm12N2t4RlRZTkFKaVJXckQy?=
 =?utf-8?B?bE9HNGVZWTYrOG13c0FjaHExLzN5VFpLOFJ5VnJRWjMvZXk0Vk5WQVkyNTlJ?=
 =?utf-8?B?N1RuaFdqMXQ1RkpaSWZubXE3eTM5Y1NCTWhEUkN2TlhmYzdNTW5PMW5ZSzR0?=
 =?utf-8?B?VlpRcFFvUUlNdWwzNnNwL1ZtR3RhRTJRQ3NnaFRyMmxCdEY2TDFtc25PVXhI?=
 =?utf-8?B?cVRHZmNKdVBNNkZQTmZyMVRLbXQ3WXowcUNoekhCWDBoVllMaUMyS04zV1dz?=
 =?utf-8?B?Mm5TK3lFSWg0VmZsRWd5NDBMNUhSWXlrWUdkYWRYTXBRNVZBNG9vNkNNRUM0?=
 =?utf-8?B?V3VxZ2xZM2RCWDJ3Z1R4RUVnT1VLREpNZkF2Q3hXQXlsakI1OFhKajVya2hR?=
 =?utf-8?B?UnVtaDdVck9XQXpWb1RLcGtjR2JQVmFCYUhhVmw5S2dSZ2ZHRDlIL2gvYzJn?=
 =?utf-8?B?RDdaTlE1Wm9zajFqWDBYMUJveWcrd1dnZHIwNUJTZGxJMG00RCtBWk43MW9U?=
 =?utf-8?B?T2c9PQ==?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a7dee060-1dbe-4794-a841-08dc66edd655
X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4130.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2024 19:11:27.0327
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 1CuIE9lcqtbo5Z+jrUzn4tTrfr0+vJjcZh60NNWlLsQidnvv915Ypos2lkCnRkjTZIucLCLerM21dhoPZWXCSQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR12MB8732

On 4/27/24 8:14 AM, Zi Yan wrote:
> On 27 Apr 2024, at 0:41, John Hubbard wrote:
>> On 4/25/24 10:07 AM, Ryan Roberts wrote:
>>> __split_huge_pmd_locked() can be called for a present THP, devmap or
>>> (non-present) migration entry. It calls pmdp_invalidate()
>>> unconditionally on the pmdp and only determines if it is present or not
>>> based on the returned old pmd. This is a problem for the migration entry
>>> case because pmd_mkinvalid(), called by pmdp_invalidate() must only be
>>> called for a present pmd.
>>>
>>> On arm64 at least, pmd_mkinvalid() will mark the pmd such that any
>>> future call to pmd_present() will return true. And therefore any
>>> lockless pgtable walker could see the migration entry pmd in this state
>>> and start interpretting the fields as if it were present, leading to
>>> BadThings (TM). GUP-fast appears to be one such lockless pgtable walker.
>>> I suspect the same is possible on other architectures.
>>>
>>> Fix this by only calling pmdp_invalidate() for a present pmd. And for
>>
>> Yes, this seems like a good design decision (after reading through the
>> discussion that you all had in the other threads).
> 
> This will only be good for arm64 and does not prevent other arch developers
> to write code breaking arm64, since only arm64's pmd_mkinvalid() can turn
> a swap entry to a pmd_present() entry.

Well, let's characterize it in a bit more detail, then:

1) This patch will make things better for arm64. That's important!

2) Equally important, this patch does not make anything worse for
    other CPU arches.

3) This patch represents a new design constraint on the CPU arch
    layer, and thus requires documentation and whatever enforcement
    we can provide, in order to keep future code out of trouble.

3.a) See the VM_WARN_ON() hunks below.

3.b) I like the new design constraint, because it is reasonable and
      clearly understandable: don't invalidate a non-present page
      table entry.

I do wonder if there is somewhere else that this should be documented?


thanks,
-- 
John Hubbard
NVIDIA


>>
>>> good measure let's add a warning to the generic implementation of
>>> pmdp_invalidate(). I've manually reviewed all other
>>> pmdp_invalidate[_ad]() call sites and believe all others to be
>>> conformant.
>>>
>>> This is a theoretical bug found during code review. I don't have any
>>> test case to trigger it in practice.
>>>
>>> Fixes: 84c3fc4e9c56 ("mm: thp: check pmd migration entry in common path")
>>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
>>> ---
>>>
>>> Applies on top of v6.9-rc5. Passes all the mm selftests on arm64.
>>>
>>> Thanks,
>>> Ryan
>>>
>>>
>>>    mm/huge_memory.c     | 5 +++--
>>>    mm/pgtable-generic.c | 2 ++
>>>    2 files changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index 89f58c7603b2..80939ad00718 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -2513,12 +2513,12 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
>>>    	 * for this pmd), then we flush the SMP TLB and finally we write the
>>>    	 * non-huge version of the pmd entry with pmd_populate.
>>>    	 */
>>> -	old_pmd = pmdp_invalidate(vma, haddr, pmd);
>>>
>>> -	pmd_migration = is_pmd_migration_entry(old_pmd);
>>> +	pmd_migration = is_pmd_migration_entry(*pmd);
>>>    	if (unlikely(pmd_migration)) {
>>>    		swp_entry_t entry;
>>>
>>> +		old_pmd = *pmd;
>>>    		entry = pmd_to_swp_entry(old_pmd);
>>>    		page = pfn_swap_entry_to_page(entry);
>>>    		write = is_writable_migration_entry(entry);
>>> @@ -2529,6 +2529,7 @@ static void __split_huge_pmd_locked(struct vm_area_struct *vma, pmd_t *pmd,
>>>    		soft_dirty = pmd_swp_soft_dirty(old_pmd);
>>>    		uffd_wp = pmd_swp_uffd_wp(old_pmd);
>>>    	} else {
>>> +		old_pmd = pmdp_invalidate(vma, haddr, pmd);
>>
>> This looks good, except that now I am deeply confused about the pre-existing
>> logic. I thought that migration entries were a subset of swap entries,
>> but this code seems to be treating is_pmd_migration_entry() as a
>> synonym for "is a swap entry". Can you shed any light on this for me?
> 
> It is likely because kernel only split present pmd and migration pmd, but I
> could be wrong since the code is changed a lot since splitting migration
> pmd was added. We either need to check all call sites or check pmd_present()
> instead of is_pmd_migration_entry() and handle all possible situations.
> 
>>
>>
>>>    		page = pmd_page(old_pmd);
>>>    		folio = page_folio(page);
>>>    		if (pmd_dirty(old_pmd)) {
>>> diff --git a/mm/pgtable-generic.c b/mm/pgtable-generic.c
>>> index 4fcd959dcc4d..74e34ea90656 100644
>>> --- a/mm/pgtable-generic.c
>>> +++ b/mm/pgtable-generic.c
>>> @@ -198,6 +198,7 @@ pgtable_t pgtable_trans_huge_withdraw(struct mm_struct *mm, pmd_t *pmdp)
>>>    pmd_t pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
>>>    		     pmd_t *pmdp)
>>>    {
>>> +	VM_WARN_ON(!pmd_present(*pmdp));
>>>    	pmd_t old = pmdp_establish(vma, address, pmdp, pmd_mkinvalid(*pmdp));
>>>    	flush_pmd_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
>>>    	return old;
>>> @@ -208,6 +209,7 @@ pmd_t pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
>>>    pmd_t pmdp_invalidate_ad(struct vm_area_struct *vma, unsigned long address,
>>>    			 pmd_t *pmdp)
>>>    {
>>> +	VM_WARN_ON(!pmd_present(*pmdp));
>>
>> Should these be VM_WARN_ON_ONCE(), instead?
>>
>> Also, this seems like a good place to put a little comment in, to mark the
>> new design constraint. Something like "Only present entries are allowed
>> to be invalidated", perhaps.
>>
>>
>>>    	return pmdp_invalidate(vma, address, pmdp);
>>>    }
>>>    #endif
>>> --
>>> 2.25.1
>>>
>>>
>>
>> thanks,
>> -- 
>> John Hubbard
>> NVIDIA
> 
> 
> --
> Best Regards,
> Yan, Zi