Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <2c800ed1-d17a-def4-39e1-09281ee78d05@nvidia.com>
Date:   Sun, 23 Oct 2022 22:42:49 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.3
Subject: Re: [PATCH 01/13] mm: Update ptep_get_lockless()s comment
To:     Peter Zijlstra <peterz@infradead.org>, x86@kernel.org,
        willy@infradead.org, torvalds@linux-foundation.org,
        akpm@linux-foundation.org, Jann Horn <jannh@google.com>
Cc:     linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        aarcange@redhat.com, kirill.shutemov@linux.intel.com,
        jroedel@suse.de, ubizjak@gmail.com
References: <20221022111403.531902164@infradead.org>
 <20221022114424.515572025@infradead.org>
Content-Language: en-US
From:   John Hubbard <jhubbard@nvidia.com>
In-Reply-To: <20221022114424.515572025@infradead.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WWFCTHR6Z2pVOHgvQ1I4UEtzZ29IZjYyQ29samZQVUM0c1FJakh1MHJGeVV6?=
 =?utf-8?B?RmhEb3N0dmM5RlY3dXlxTmxRRVJxR0t4cWtBR2RFVHc5ODlCU2pnWmlQT25Y?=
 =?utf-8?B?MFVzU3pucWRoZ1RsVVA1dEF3akxENzROc0Fua1ZSeHhKSHJybTJSd2lRVjY4?=
 =?utf-8?B?WVNFeEowTzJUaEVJaU5kM25lS0wzMGZadWtIRlprWHNnb3RLcVVtemVDQ2Ny?=
 =?utf-8?B?NlcwVTd3NWdUNVIvQ1ZzNEtxS0l2SWJ0VU01SW1iRzF4dEkrQkcwMnV6S1BC?=
 =?utf-8?B?aWZVTGc3RG9PdEJmSEgvWmRrRkgrTVdPc3ZwRlR0TUJpczZ3MS9YQ2lGM2FC?=
 =?utf-8?B?SVpsRHZDeDJlVUsvNTlXNUFhd2xOSUQzMmRhVnp4OXk1eGpRZk96RVpBRzlz?=
 =?utf-8?B?OWhEQXlEMmJRWmtZdExjbnkyclorMlBCWHFzTmZYR1pDeVRvUmlxK3h2T3dW?=
 =?utf-8?B?eGUzTTBDaWN0b2sxeUdkRVB3TGs1TzN5a29QSnVZMjQrQk5ra0hQc25uMkJX?=
 =?utf-8?B?U09VSGZGVG1RR1Q5MHJRbkJSMkdNVHpmYmw4VnltTi9MSkZicjdXS3BMZ1U4?=
 =?utf-8?B?Vmd5cWViUzJVM2wvUjdBdFBGKzNmQUdLWXd6RzhKSzBkSXZ4a3dHR0x0V1pE?=
 =?utf-8?B?S216UVB2SHNXUWVXTUtLOGVVNGppai9VdjhpQnl4anBrbWx5TXNmL0RpSFp1?=
 =?utf-8?B?TTRhejdmcU5ubktpelZ2d2pYWllwaDBwSzNPdS9GUDhib0VPVEJyRkduQWlG?=
 =?utf-8?B?MWd5QnZIbnhNcm9EZlo5QWVWRUxYNDVyWlRGbDJBTXJ3VDBnbXBiY21GYWt0?=
 =?utf-8?B?YmpTalFzeUUzMVlWU1MrRnVjTUlMOXRGMVc2Q054czZWUDFyU2VyYUpUSWZy?=
 =?utf-8?B?VjdUWHZBcEtndk5wamlMeW9IanFEOThzY3RTRXVIM3I5d2RFTnJzeEpiNnFU?=
 =?utf-8?B?QXBpU01rbVFVYmsxbnJRamlZK2RCcjAya2k5Qm16SEJDazEyNzZ1cHFaYUx1?=
 =?utf-8?B?anFmVzJCSU5mbUVKQWhiSHJCT3k4ZlUwM1VRc0VaNUJpd3dEalBZbE9rSkR6?=
 =?utf-8?B?Z0VlZ2krdjZIZjV1MmdoenBKeGM3OTVBemFtZEJmYXF4Z1JuUG9vWG9Ock5k?=
 =?utf-8?B?WDFHemU4WnBHVVVXcVZSUURLRytvSXRVK0VzWnFjWkNuMldNK2s5VXpzd2xL?=
 =?utf-8?B?RFNEbHVUcGZmdWFXUDdtaUdnTXNFbVNYQ2Zwb0xZNyttbkQwMEl1QnEyaUZ6?=
 =?utf-8?B?WmZCSXUxU1VTUHpDYkNqWFpiNTU0L0JpNWZ3K1JGalZQY0JnbXpCNy9XVFBH?=
 =?utf-8?B?UVlPbmgxUlhEVUZocmh0OWxFY2NTNjJCVHR1UHRXd1BNYzZkQ21EZjFaUEZu?=
 =?utf-8?B?M2RFaVhCMHZVaU1mcTN3MzZXakVMMGF3UWZ3NzIyanJPODVIOFNTNGlSR2NQ?=
 =?utf-8?B?aEZRVU5UbUFONWd4eFkyUHJPbU5TZjNVcGkzNlFEVk1STVZXajMrUjZmWHRZ?=
 =?utf-8?B?OURUWEV0L1FOclZvSzI3czIwLzVXdUVQNFc2WWlDSGNSaUtHRWs4a1Zsenh5?=
 =?utf-8?B?NjNNVjd6bm9URXpiN0JsRlM1UDUxaERLWUt2MjdjZ1QyMFBzUGtCYmRKRlVK?=
 =?utf-8?B?WERSUU1pWkNLUmRZOGNCUVV2RERtMUV6OWlZdzM3bXRsQUE0WjBPZ3N6Z0pl?=
 =?utf-8?B?U2grY1JhbGRtcVl4S0ZuSmtCZSsvRlVRT2swM0FybVYxbTl0dEFCOFBwRFJF?=
 =?utf-8?B?Z1lpTDJiVlhtZDA5VnYrZWxLVzdPYU85SStMTnd4UWp2b0tidUlremZoRTdi?=
 =?utf-8?B?WU9ZeEhvbzRBaE55eGowbjIwREduYm5DaTFaaUtiOFRaSkNOV3pHQnp6TkFx?=
 =?utf-8?B?MkNITUhGNUN5V0ZiYno2Y0poTWpuSHhDQWNJMk1ObklodXJHZE9iMk16ZkFE?=
 =?utf-8?B?OW1obTU2d1VSd3lCQVp4dG1lODVJaXJ6RkJwNXJCbk1QWUhTaFErTnFydzNJ?=
 =?utf-8?B?UGRIMTA3N0diK2cvaEtaQmt3d0ZjUTVJdGhaYW1NT05nWU1LUlhGSlZFNzhN?=
 =?utf-8?B?WG5sSElYaDFIb29PNFZ6S3gwTEtQV0lSMk9Tcno5UzFtZm1mMStqM2NvUFdW?=
 =?utf-8?Q?pzlZthDumPzwM91nz94YZlIzA?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 336cfb6f-29f5-4de0-ebc5-08dab5829786
X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4130.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Oct 2022 05:42:52.1124
 (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: aCqewyR7GmqoHm6nm955UKo0bfG1g28LHBg/AoTaERpY8a3/NyceqegFMFnVlbAK9Gfbvxoerr2kaFZdMqWiVA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB6231
X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,
        SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 10/22/22 04:14, Peter Zijlstra wrote:
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -260,15 +260,12 @@ static inline pte_t ptep_get(pte_t *ptep
>  
>  #ifdef CONFIG_GUP_GET_PTE_LOW_HIGH
>  /*
> - * WARNING: only to be used in the get_user_pages_fast() implementation.
> - *
> - * With get_user_pages_fast(), we walk down the pagetables without taking any
> - * locks.  For this we would like to load the pointers atomically, but sometimes
> - * that is not possible (e.g. without expensive cmpxchg8b on x86_32 PAE).  What
> - * we do have is the guarantee that a PTE will only either go from not present
> - * to present, or present to not present or both -- it will not switch to a
> - * completely different present page without a TLB flush in between; something
> - * that we are blocking by holding interrupts off.
> + * For walking the pagetables without holding any locks.  Some architectures
> + * (eg x86-32 PAE) cannot load the entries atomically without using expensive
> + * instructions.  We are guaranteed that a PTE will only either go from not
> + * present to present, or present to not present -- it will not switch to a
> + * completely different present page without a TLB flush inbetween; which we
> + * are blocking by holding interrupts off.


This is getting interesting. My latest understanding of this story is
that both the "before" and "after" versions of that comment are
incorrect! Because, as Jann Horn noticed recently [1], there might not
be any IPIs involved in a TLB flush, if x86 is running under a
hypervisor, and that breaks the chain of reasoning here.


[1] https://lore.kernel.org/all/CAG48ez3h-mnp9ZFC10v+-BW_8NQvxbwBsMYJFP8JX31o0B17Pg@mail.gmail.com/


thanks,
-- 
John Hubbard
NVIDIA