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;
Date:   Thu, 3 Nov 2022 11:38:25 -0700
From:   Mike Kravetz <mike.kravetz@oracle.com>
To:     Peter Xu <peterx@redhat.com>
Cc:     linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        Andrew Morton <akpm@linux-foundation.org>,
        James Houghton <jthoughton@google.com>,
        Miaohe Lin <linmiaohe@huawei.com>,
        David Hildenbrand <david@redhat.com>,
        Muchun Song <songmuchun@bytedance.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Nadav Amit <nadav.amit@gmail.com>,
        Rik van Riel <riel@surriel.com>
Subject: Re: [PATCH RFC 02/10] mm/hugetlb: Comment huge_pte_offset() for its
 locking requirements
Message-ID: <Y2QKoYtj9mthpHBk@monkey>
References: <20221030212929.335473-1-peterx@redhat.com>
 <20221030212929.335473-3-peterx@redhat.com>
 <Y2PhSUnufjkoqSaH@monkey>
 <Y2QEU53BMDgEHXbG@x1n>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y2QEU53BMDgEHXbG@x1n>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?0ylqNGm4hw4DJ4BnsXH+3EBJ+ZVuGeDbChOrcVFprLcPEpPKtDtkR2Swj7VG?=
 =?us-ascii?Q?sTujESiog62h61b2boDj1fZiwwBrfkDtnVY2hWT2JUGLIdzc6roMQi5FdB1Z?=
 =?us-ascii?Q?A81Lm+8xfOSLPxS2S9IF1b7TyQDcpS4GyG69taEXOtQDTUwfPrWmRCxpsFyp?=
 =?us-ascii?Q?xF5u0UIuDEaNxSAvtxj0X35UVYYwuCojvzU8+sJKiUVmAq7GvY/xaBf1KYJ4?=
 =?us-ascii?Q?gIWc3Cb/UWLRGMQskVQLwyIRRcJ6eV2yO9OEWnwrO2SCq2aTgCNmXDJoFbqQ?=
 =?us-ascii?Q?4+USeKpOPFSliuFH+85pTYnnotWY2aZxC14M1Q4cmb/hVD/Vr43p/4XAhIuX?=
 =?us-ascii?Q?rqro2govTmz/xwJlH5mrEBrvb/uNnr9B12SZX7dc3s8LqloFfQADs26o2UFj?=
 =?us-ascii?Q?HJ3JVfckp+CNSR7pXaohaGa7InyLyK90Sm1pmxzY7MdfaTTWSiY6XpdrZ3ZF?=
 =?us-ascii?Q?jMHaCaPLxXiJirpw15PSDclihSgfv3EbiEGU0larhRy6vM8RA0eILyYv0JIP?=
 =?us-ascii?Q?OQtp5vweN3J50WJ3Y2MAqyAd6tY7Baf1P/2EDJLegBbZWGJI9NIeWVWEQPnv?=
 =?us-ascii?Q?DtAJFllNXaWwxuGyH8F0if72UiJNRPTOeBy/06+QtrhUiQY1GjIpR9sYYKSf?=
 =?us-ascii?Q?jyReihhkV+ikT3WjetUPVzt0Fhi+1nuDDHYEum4N5x+gn3ksOF8LWuUMkg0H?=
 =?us-ascii?Q?meX+G2tbvHhvoLSKV+5uU1GoZTaQF6ORMptTjI1LUnQRQUHfoWGjNYfg5B6o?=
 =?us-ascii?Q?tqA8t1GespThUjmfhaPAIRE9CmOVeDL0KqY/P1Qt0TtIxoLQzas0JIlhRKmU?=
 =?us-ascii?Q?vSnQRcSLEhMtT4ZaoRfcwVU6wLSNRfe9+Rp209q1I+nTiekQGSDTtGjUPAFj?=
 =?us-ascii?Q?GcsF82OvdQJ/J8KMDRzI2Eo3jdvrqXxwcrb0yHRAWH22Xsy030zPIug4GCSu?=
 =?us-ascii?Q?Bpx4cSeDXnLZbU5Cd+H/GwhzDfPIe1/MTH8jkvsumi1DxloGJpWwiDhj3k00?=
 =?us-ascii?Q?kwxZsp0GCKsh+7kYTNBtqTTlC+7s78Zz2lOsIPj4JHoxTbVjMlu0Q0WZV9uM?=
 =?us-ascii?Q?xU05JpUrz/S810m/CmEfQHsl2TMrrxcRE52WhE7omLUR0vJ3YIVv8HkLNF2W?=
 =?us-ascii?Q?hzvILyM9ZSwJNPbFZUX6zsAFjAlH9a2wp077G/2WnrONOl+64s5+ELohcf4b?=
 =?us-ascii?Q?OmiIDPZi4tUyOJg7A517kP8mYAipUVKr9gkKkRVUD782qv0lyOAjhStDVk8C?=
 =?us-ascii?Q?hHNbD07jiCSPJlds0ts9SGfPJFdNS06Q0aZV6M1xJijAdplc8eX9Ns+F+9j5?=
 =?us-ascii?Q?rM7VTbFXHeaADJ4+lfrEJAa94kVUTu1SHM52ipDvjUjmbQr3n60rIZdE5IiI?=
 =?us-ascii?Q?Cjqh2MjWUJaIvQyWk5dzz8BXIN2IRxAIdfRqbGYHUG11SDrQYjc4no/hNreu?=
 =?us-ascii?Q?XPKsoYiY3uxOEDNfXEChws00bEhJfUUw0aj7nbEuhzpN1xLadISTsRA+o7GC?=
 =?us-ascii?Q?3yUTXJBhkeRi3rgg1V9J8HXCTHqS5wzjL9k6ikgMyr8baF70oBNmHnInElvw?=
 =?us-ascii?Q?C/Ydj+LunnRasmNlUELhyiAvSt3QxUhbFJjwhSVAFPX1iVy8iSK+uPPfKKNA?=
 =?us-ascii?Q?oA=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 92e0d9b9-ef8f-4b74-4a3f-08dabdca9b79
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2022 18:38:31.7213
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 50b+8n/Dvx5uY0amnt9viS1+WFbAU/a6wOuuyF3ZzXqUKKPTMlN7/5L5J33xgxIkz0nAu7oIGTd1c71ofDS2Qw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR10MB6654
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-11-03_04,2022-11-03_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 phishscore=0
 mlxlogscore=843 suspectscore=0 spamscore=0 malwarescore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000
 definitions=main-2211030126
X-Proofpoint-ORIG-GUID: K56XZ482D4Sj9hY4xvOek2GtFfSxDIp9
X-Proofpoint-GUID: K56XZ482D4Sj9hY4xvOek2GtFfSxDIp9
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,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 11/03/22 14:11, Peter Xu wrote:
> On Thu, Nov 03, 2022 at 08:42:01AM -0700, Mike Kravetz wrote:
> > On 10/30/22 17:29, Peter Xu wrote:
> > Not sure if it is worth calling out that we are safe if the process owning the
> > page table being walked is single threaded?  Although, a pmd can be 'unshared'
> > due to an operation in another process, the primary is when the pmd is cleared
> > which only happens when the unshare is initiated by a thread of the process
> > owning the page tables being walked.
> 
> Even if the process is single threaded, the pmd unshare can still trigger
> from other threads too, am I right?
> 
> Looking at huge_pmd_unshare() callers, the major ones that doesn't need
> current mm context are:
> 
>   - __unmap_hugepage_range() (e.g. hole punch from other process on file?)
>   - try_to_unmap_one()
>   - try_to_migrate_one()
> 
> So for example, even for a single thread process, if its pmd shared with
> another process, the other process can do (1) punch hole on pmd shared
> region, then (2) munmap() the pmd shared region, then it seems the single
> thread process can be still on risk of accessing freed pgtable.

Yes, you are correct.  I was not thinking about an unmap initiated by another
process doing something like hole punch or truncation.
-- 
Mike Kravetz