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 A1A31CFD352 for ; Fri, 11 Oct 2024 11:29:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 359996B00B7; Fri, 11 Oct 2024 07:29:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 308016B00B8; Fri, 11 Oct 2024 07:29:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D1066B00B9; Fri, 11 Oct 2024 07:29:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id F1CA86B00B7 for ; Fri, 11 Oct 2024 07:29:52 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8A6D2A0C6B for ; Fri, 11 Oct 2024 11:29:44 +0000 (UTC) X-FDA: 82661101782.09.E38ED9B Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf18.hostedemail.com (Postfix) with ESMTP id 1B76A1C000A for ; Fri, 11 Oct 2024 11:29:49 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf18.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728646038; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Xqx43qy3etwS8i1GnylNYMl+T2IDAJaM9c7PgiIiIac=; b=aOU7avZu6B1sLxjbxQxQD8AIbwIGWnptXNAolSYuRlsy/UWg8NM+yE0+bQGyISoM+M9Nn8 iF858VXBvsoCC0pIPyCkEBMlV09JOt+nKkP2FzcqWi3p1nL+vpUlwCuL8wijXJ3pZe1nj+ O3NSZFBiZJT1ec76kXe5B8DMq5qHbSg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728646038; a=rsa-sha256; cv=none; b=y7dGijn73Ds7lT/OZs8nMULAU/tCiZAAKh25NcQIEmd4RXGcM3SqyFzwT+vo4mFZNu50Fb /F1jMyoRsg6kj3lzFgbrDAxi0yX5tbYUNaCW3AO2rYkFw/NnGycVF703bfNVMUG9MIOI4l yPENAJdO0q6g4pHmc3b6Z8wr/MbWMw4= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf18.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 678CA497; Fri, 11 Oct 2024 04:30:19 -0700 (PDT) Received: from [10.57.85.162] (unknown [10.57.85.162]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 837E63F73F; Fri, 11 Oct 2024 04:29:47 -0700 (PDT) Message-ID: Date: Fri, 11 Oct 2024 12:29:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 2/2] mm: don't install PMD mappings when THPs are disabled by the hw/process/vma Content-Language: en-GB To: David Hildenbrand , linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, kvm@vger.kernel.org, Andrew Morton , Hugh Dickins , Thomas Huth , "Matthew Wilcox (Oracle)" , Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Kefeng Wang , Leo Fu References: <20241011102445.934409-1-david@redhat.com> <20241011102445.934409-3-david@redhat.com> From: Ryan Roberts In-Reply-To: <20241011102445.934409-3-david@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1B76A1C000A X-Stat-Signature: 6tcznpidps9fxk9qi7jk3g87fummgzym X-Rspam-User: X-HE-Tag: 1728646189-290945 X-HE-Meta: U2FsdGVkX1+qWPK075Bs5NvrMMTg53BGH7cVCYvblZhjzl48xRSewR4ZVdbLYEv4VACE1PVM/G9aqW4557BECYPzdVOGQPAqU7DEOyj2eYfdjVofE2s8lHNQIctKWfXrNt/4Lz3ojODiahZoIj+qAV+MK+LsYmbQ9hF+CVyRU7HD0ZBPu6S3MzAR74FRtP9VMSItoM7eltc4kc9FMPTqDuNFt0NqmQJadweNZuzqo5g9N45mxCWnY+PHqWxfaDmp8OH8kp7g8NII1BgqWrdBroQg4xAUe4iZ4LDdQy7xYjpi8PQvu2qF3wxzsicpz8HrPgCQiMbWOXCQeoHsLwopNDUr2tdwvnwYDGkvQAmfhnuE43CguC3bmSllaV0++sAP3T8V/TCpqHVPSovoC3CXZ73ammFwrfli9CmWOpjgToR9+xZmAYgRFCtI8N7lnnNp/QLnIEhkBcPsu736qifq+RpJUOsySSyYmYG1wlONOjligNhssm7dtU/jP6N3Ym9AGJR6p442cuT6I5n/GNkQ7HWoImH6hPlWe6/p1X8OqJ8AQ2Oxh04v9gRtnfs3Otp0GG2qnTzP6VxZyetFaeZxoqd9Aqrqiq73RnlY3rg+sy9A9MyiBFM3rArsvX8a65AqaNgYBlN06WsF24xji/lRupj8T8JN4ACyoo7l+aIL5cu8xU7jD0ZXQghaiwUEsJZO7cK+oDW+jXTA5X+exANSF/obHqnZAW1UbRtOef6HEGXi16DmM0Z7iFe5pnffSI0/m+4lQvZVKGLnc+5OUaOY1F1v55ZwAvDuk7+KJg4guWTc0Kwzeoj1OJDishe/w3K9eeUaGHxIyIiVNmABREy/sgoznnPhLxtdwWPfEpM5le0O572ANGU8z1CZZ4HsXY10kUxtYU5cEC9Mtb+R3NvRRfTts+zle23cdr+NgOodtrRjkqX1kVJWFXGd/25/VNb3wi0Q0VQll8xgJDX978g 0D0stGRA 2LBkIJZZcfteOqL5UM070o0A9ofifEbcW3nG6H/WlG4wPslFaKbE97AXmOsqaSZeI92igfTwR8ZL53EZ8y/A7W2xTGTBjI0SOqJOPA/w+jd4Q2S8WEPYhcVbZkLaXqV5KRQiZyLrLlMKkwWsXuCDQ5kOXKxDwzGiKltbwP9Y0CJfZewKSjmvX0L/nGbyNXJDpfZKdRudT+J9zRdhEbiNfQdWOoGUAxUsTY/3ucgIyrFamLYinLYvm01sj8dOOeFtjcVE3MOck7SBgmU4Jx39hsiiHzkvByWdsS1zKAJHygFoSt/GHtW7t+3B2eQ== 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: List-Subscribe: List-Unsubscribe: On 11/10/2024 11:24, David Hildenbrand wrote: > We (or rather, readahead logic :) ) might be allocating a THP in the > pagecache and then try mapping it into a process that explicitly disabled > THP: we might end up installing PMD mappings. > > This is a problem for s390x KVM, which explicitly remaps all PMD-mapped > THPs to be PTE-mapped in s390_enable_sie()->thp_split_mm(), before > starting the VM. > > For example, starting a VM backed on a file system with large folios > supported makes the VM crash when the VM tries accessing such a mapping > using KVM. > > Is it also a problem when the HW disabled THP using > TRANSPARENT_HUGEPAGE_UNSUPPORTED? At least on x86 this would be the case > without X86_FEATURE_PSE. > > In the future, we might be able to do better on s390x and only disallow > PMD mappings -- what s390x and likely TRANSPARENT_HUGEPAGE_UNSUPPORTED > really wants. For now, fix it by essentially performing the same check as > would be done in __thp_vma_allowable_orders() or in shmem code, where this > works as expected, and disallow PMD mappings, making us fallback to PTE > mappings. > > Reported-by: Leo Fu > Fixes: 793917d997df ("mm/readahead: Add large folio readahead") Will this patch be difficult to backport given it depends on the previous patch and that doesn't have a Fixes tag? > Cc: Thomas Huth > Cc: Matthew Wilcox (Oracle) > Cc: Ryan Roberts > Cc: Christian Borntraeger > Cc: Janosch Frank > Cc: Claudio Imbrenda > Signed-off-by: David Hildenbrand > --- > mm/memory.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/mm/memory.c b/mm/memory.c > index 2366578015ad..a2e501489517 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -4925,6 +4925,15 @@ vm_fault_t do_set_pmd(struct vm_fault *vmf, struct page *page) > pmd_t entry; > vm_fault_t ret = VM_FAULT_FALLBACK; > > + /* > + * It is too late to allocate a small folio, we already have a large > + * folio in the pagecache: especially s390 KVM cannot tolerate any > + * PMD mappings, but PTE-mapped THP are fine. So let's simply refuse any > + * PMD mappings if THPs are disabled. > + */ > + if (thp_disabled_by_hw() || vma_thp_disabled(vma, vma->vm_flags)) > + return ret; Why not just call thp_vma_allowable_orders()? > + > if (!thp_vma_suitable_order(vma, haddr, PMD_ORDER)) > return ret; >