From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02110C77B7D for ; Wed, 10 May 2023 08:21:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51AB26B0071; Wed, 10 May 2023 04:21:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CB116B0072; Wed, 10 May 2023 04:21:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B9D56B0074; Wed, 10 May 2023 04:21:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2ADC46B0071 for ; Wed, 10 May 2023 04:21:49 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C34E180772 for ; Wed, 10 May 2023 08:21:48 +0000 (UTC) X-FDA: 80773651896.27.99AE30D Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) by imf29.hostedemail.com (Postfix) with ESMTP id C278C12000D for ; Wed, 10 May 2023 08:21:43 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=CzmDvf3r; spf=none (imf29.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683706906; a=rsa-sha256; cv=none; b=W4JLYSo1HaS8p7p37EL/KCO9/LBc0idyv/oFkVMkJNlbw108JMCtC5XZ0pQ4401k0xFad1 Czm/Ecw6J3Gq9OHyf2p3j3T5RkyyrVP0It2P9YWoo5Ujd2SDM6yx6KvYDEsUEryPOv4aU7 OcAjfSwUw+LGZEy1jhA3wXay45pv/rc= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=CzmDvf3r; spf=none (imf29.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683706906; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1WZCLagr9yk4Cbp+6qSxxsSMmqvOctxqT3bVkNGFhnY=; b=x6MOstKoil6NMIQxAeNnZyXNTUaGDGWphDW4karAsdZYRdyZdOjuzayprPboZD8QmzWy9x azmLTvQJ/C+D+AblB7TtgFW014WKor9p4aGtcRb/ypOfSY6hCF1tAuRt8bn8h205I5bqnK iLgBQQbcwbThOBGdYQhuGLR1B1yFVL0= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=1WZCLagr9yk4Cbp+6qSxxsSMmqvOctxqT3bVkNGFhnY=; b=CzmDvf3rqlZoWLTgd3FVOKNA13 am3KRsvw5dx0zZtORpSkeQixmHm2I0T/j68VXo57hz3B2sKfsZlkzT6mcIfsGM8QExy3tEBmFQg15 5knvERiYGPZKMBkmsOAK/iQ/5rtOFvAqMTYH7nFMXqdqWWfvmHjqNDYraw79BjtqAXxEKvC5IXPLi v4WkUXSf6SdYO2DxNqGoNj/9jzwXI/RVqLwvIK8H89K9xhFYfEkKkPofOod7rLsPcDYQd4FB4I+bb ncPfZdYjPCu8FZ1ut2ZqCkZjLMrUhqEHRkvEROX3xUgFItRMwb3mnY6amim7reKFoxZZ2cjlGh5hD cm+pskqQ==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1pwf2E-007PM8-2r; Wed, 10 May 2023 08:20:55 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 4DA20300338; Wed, 10 May 2023 10:18:48 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 2369E20B04BA2; Wed, 10 May 2023 10:18:48 +0200 (CEST) Date: Wed, 10 May 2023 10:18:48 +0200 From: Peter Zijlstra To: Hugh Dickins Cc: Andrew Morton , Mike Kravetz , Mike Rapoport , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Suren Baghdasaryan , Qi Zheng , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Greg Ungerer , Michal Simek , Thomas Bogendoerfer , Helge Deller , John David Anglin , "Aneesh Kumar K.V" , Michael Ellerman , Alexandre Ghiti , Palmer Dabbelt , Heiko Carstens , Christian Borntraeger , Claudio Imbrenda , John Paul Adrian Glaubitz , "David S. Miller" , Chris Zankel , Max Filippov , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 21/23] x86: Allow get_locked_pte() to fail Message-ID: <20230510081848.GD83892@hirez.programming.kicks-ass.net> References: <77a5d8c-406b-7068-4f17-23b7ac53bc83@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: C278C12000D X-Stat-Signature: 1epqskcbqjidhr7a7r8mnoo536o6dqsh X-HE-Tag: 1683706903-273339 X-HE-Meta: U2FsdGVkX18AoZtBpfq1MMrzpQ0taKJdGjub80vKHzV1g8u4Rr6W+z4AJsu8bZTOBptP8vqmJ/OU/OEPu6QL2zUmdhS4NuDI04EEZykeGgtDU2bOf/+dBx+eETzTtVVFTnzPEuE86dQroCXoV+UvwMrKHX2U5wHifPe0naPy6Lv3Oo3H0N1YHOuJBJmzXv8QFxeBWfMR7PqMcKYJLjFSlnshyqpezFUqJZmxEp81N/nWH2XL2ldwQENPV8hFWmJgIaVXB10/nSQkVZRvHgkBIFjTI9AC3jsdMo2uv6WzJwQfr1dWTsINs+3cpNBHvCiS/romOQ/kYNBvSkfnfyLjYuT28He3IxOMfZgW9VlOLiZk1FVQ7VtI9ebwUc81Cbr82NF5ddWnSyeg/32kbcjeitqX/M7UXVHMx8C36fCSGWKiZLProQptpv+QmqYWxp4W2+v949hSh3HKyhVw4ZQZUq8n65gZBsNBB/FPZHePFzwRFZKCB+GEInDdBHZyhA/rbs1ZG4XMzlzOR5Pi1Ba/2Vw365MxsQJh3cICk9DZ7fROlPGlR8PDzU1+0NmkKTow8qdPcyfhWWi9wMP1ed6cB334v0Q8BiD0QGt/IdJaT8Z+VbTtKHaw8rmcE2gGEoyOIhxlXpItR3mptxHsBrsUi6Juk/1l+VhjIAjsU4YvXDyZr9CE40Kx824fh2goW5m9IIJD5j4VK0abd5ApwnBWU1AxhmZ3nKcgvP0inkW3/qV3UDV+f2BIfqF9gdmMjH2mLipfc3aGDQ11YS7eFDPhr4I24UK8Z0jxWqmGWrSEszV0pwKRMQ3VwFGpSc2OYTrIXsNykKX3tlKf1KbJQ91muGK/BB5jPs97Gbsc3fYwQ0Mc7MOd3hm3Um/AT7HpS8sNZhkb3c0dX63f7zybuzeVE515N5JPIboRitx1QjE++sZ2xo7MeUEClvrvWQb6w5lli0Vs/sVi5IkNbv0KNoj +gNmbBEc jYQmg6spWRn8/4m9TVj6FyHabm49Rm+la1uMflrrZsG2zm9gHDCUaAMxKwdGFJn5IrkPokKXE6rWt0tJCh1tNjUyHN+ha6dIjCUZ9v7tgwKBjpxSQIWS1Pkk/e3OT2Ya1gXYqlZhRzMkBVsR+5CKGMhgWEdLdrZHh5i0miZW5k/i/LK+YCLdXr/KH6eeseQUcNFuWqe4JGWParxguzqL11liVtA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, May 09, 2023 at 10:08:37PM -0700, Hugh Dickins wrote: > In rare transient cases, not yet made possible, pte_offset_map() and > pte_offset_map_lock() may not find a page table: handle appropriately. > > Signed-off-by: Hugh Dickins > --- > arch/x86/kernel/ldt.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/ldt.c b/arch/x86/kernel/ldt.c > index 525876e7b9f4..eb844549cd83 100644 > --- a/arch/x86/kernel/ldt.c > +++ b/arch/x86/kernel/ldt.c > @@ -367,8 +367,10 @@ static void unmap_ldt_struct(struct mm_struct *mm, struct ldt_struct *ldt) > > va = (unsigned long)ldt_slot_va(ldt->slot) + offset; > ptep = get_locked_pte(mm, va, &ptl); > - pte_clear(mm, va, ptep); > - pte_unmap_unlock(ptep, ptl); > + if (ptep) { > + pte_clear(mm, va, ptep); > + pte_unmap_unlock(ptep, ptl); > + } > } Ow geez, now I have to go remember how the whole PTI/LDT crud worked :/ At first glance this seems wrong; we can't just not unmap the LDT if we can't find it in a hurry. Also, IIRC this isn't in fact a regular user mapping, so it should not be subject to THP induced seizures. ... memory bubbles back ... for PTI kernels we need to map this in the user and kernel page-tables because obviously userspace needs to be able to have access to the LDT. But it is not directly acessible by userspace. It lives in the cpu_entry_area as a virtual map of the real kernel allocation, and this virtual address is used for LLDT. Modification is done through sys_modify_ldt(). I think I would feel much better if this were something like: if (!WARN_ON_ONCE(!ptep)) This really shouldn't fail and if it does, simply skipping it isn't the right thing either.