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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F033CC6FD1F for ; Tue, 2 Apr 2024 16:00:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=++BNUHttbIwpyka+zhyIaz2+3MK0jMFGvJSM3jfjXmA=; b=BZ25rai9XoAwut Jt8GMOPH60G9in2B9cw1CTj7sbxtD60NH0oGMJpmj53QuUaHwFKel4+Sigfbp6z7jsaAALf8ad4rq 2qed1zMYMqL+9HkWCAhqqsnV5bapM6W1MGEg8T756U/UTFfSdebaRaPe3s+0NiaDs6xs8jyuFQURi mOHok2qs22ZCfIEdG8C/5U4cK9UYscCUA6DnwmqSEStxb2FERMox36tKddQR57R4bItqVBnAaYv1x 06OUh7e8U0QTFMVPp/bw+AZpfrazi2TVRWDSKi5Dd3J/MPFx4s/qEp3bm+8GDq1EUZMU5t5vjUojW HcEpi8urHGH2A4UmhhOA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrgYW-0000000BvuN-3VRf; Tue, 02 Apr 2024 16:00:12 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrgYU-0000000BvsL-3XYE; Tue, 02 Apr 2024 16:00:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=J1C2/bPg/F9WrdiBHSYL5RX039VeHvKnxuGgTbDm1H0=; b=R2IN4t4he6Ikh2eCoolYn2D1ln bR/xnpgwp5nTMZdagY0yP7uhv+3h48ujjYE5yB9UplVKqXGoqHhQDFx6Jkksdob89JG3X92Toiy2n tpdQXC31wQj8/IoO4Y+ZlLIelTem8wG91gEnWIZCkA/fbYyUxmEHFosVKc03Os3c8PAmqwJMB0gB9 hyAJUfPQ7tDBLByuN78X7TsKnwe4D8xS+YIdylZ9PDwDcfTzdsT+W4Zn0ntQp+aMaESEJLalvpLlI gcDIt6Sh0qyQ2cSKN8hyf81O7nNdTQGTV5wXPOX30EbVaeNoRNVmi6sGvQxqceiq9vEjpBDFFKqBe GnoA5Zzw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrgYO-00000003OYG-2Yps; Tue, 02 Apr 2024 16:00:04 +0000 Date: Tue, 2 Apr 2024 17:00:04 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Ryan Roberts , peterx@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yang Shi , "Kirill A . Shutemov" , Mike Kravetz , John Hubbard , Michael Ellerman , Andrew Jones , Muchun Song , linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, Christophe Leroy , Andrew Morton , Christoph Hellwig , Lorenzo Stoakes , Rik van Riel , linux-arm-kernel@lists.infradead.org, Andrea Arcangeli , "Aneesh Kumar K . V" , Vlastimil Babka , James Houghton , Jason Gunthorpe , Mike Rapoport , Axel Rasmussen Subject: Re: [PATCH v4 13/13] mm/gup: Handle hugetlb in the generic follow_page_mask code Message-ID: References: <20240327152332.950956-1-peterx@redhat.com> <20240327152332.950956-14-peterx@redhat.com> <5d9dd9a7-e544-4741-944c-469b79c2c649@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5d9dd9a7-e544-4741-944c-469b79c2c649@redhat.com> X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Tue, Apr 02, 2024 at 05:26:28PM +0200, David Hildenbrand wrote: > > The oops trigger is at mm/gup.c:778: > > VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page); > > > > So 2M passed ok, and its failing for 32M, which is cont-pmd. I'm guessing you're trying to iterate 2M into a cont-pmd folio and ending up with an unexpected tail page? > > I assume we find the expected tail page, it's just that the check > > VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page); > > Doesn't make sense with hugetlb folios. We might have a tail page mapped in > a cont-pmd entry. As soon as we call follow_huge_pmd() on "not the first > cont-pmd entry", we trigger this check. > > Likely this sanity check must also allow for hugetlb folios. Or we should > just remove it completely. > > In the past, we wanted to make sure that we never get tail pages of THP from > PMD entries, because something would currently be broken (we don't support > THP > PMD). That was a practical limitation on my part. We have various parts of the MM which assume that pmd_page() returns a head page and until we get all of those fixed, adding support for folios larger than PMD_SIZE was only going to cause trouble for no significant wins. I agree with you we should get rid of this assertion entirely. We should fix all the places which assume that pmd_page() returns a head page, but that may take some time. As an example, filemap_map_pmd() has: if (pmd_none(*vmf->pmd) && folio_test_pmd_mappable(folio)) { struct page *page = folio_file_page(folio, start); vm_fault_t ret = do_set_pmd(vmf, page); and then do_set_pmd() has: if (page != &folio->page || folio_order(folio) != HPAGE_PMD_ORDER) return ret; so we'd simply refuse to use a PMD to map a folio larger than PMD_SIZE. There's a lot of work to be done to make this work generally (not to mention figuring out how to handle mapcount for such folios ;-). This particular case seems straightforward though. Just remove the assertion. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 745AAC6FD1F for ; Tue, 2 Apr 2024 16:01:13 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256 header.s=casper.20170209 header.b=R2IN4t4h; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4V8CKg6cw8z3vYs for ; Wed, 3 Apr 2024 03:01:11 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256 header.s=casper.20170209 header.b=R2IN4t4h; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=infradead.org (client-ip=2001:8b0:10b:1236::1; helo=casper.infradead.org; envelope-from=willy@infradead.org; receiver=lists.ozlabs.org) Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4V8CJm2CW1z3dLQ for ; Wed, 3 Apr 2024 03:00:23 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=J1C2/bPg/F9WrdiBHSYL5RX039VeHvKnxuGgTbDm1H0=; b=R2IN4t4he6Ikh2eCoolYn2D1ln bR/xnpgwp5nTMZdagY0yP7uhv+3h48ujjYE5yB9UplVKqXGoqHhQDFx6Jkksdob89JG3X92Toiy2n tpdQXC31wQj8/IoO4Y+ZlLIelTem8wG91gEnWIZCkA/fbYyUxmEHFosVKc03Os3c8PAmqwJMB0gB9 hyAJUfPQ7tDBLByuN78X7TsKnwe4D8xS+YIdylZ9PDwDcfTzdsT+W4Zn0ntQp+aMaESEJLalvpLlI gcDIt6Sh0qyQ2cSKN8hyf81O7nNdTQGTV5wXPOX30EbVaeNoRNVmi6sGvQxqceiq9vEjpBDFFKqBe GnoA5Zzw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrgYO-00000003OYG-2Yps; Tue, 02 Apr 2024 16:00:04 +0000 Date: Tue, 2 Apr 2024 17:00:04 +0100 From: Matthew Wilcox To: David Hildenbrand Subject: Re: [PATCH v4 13/13] mm/gup: Handle hugetlb in the generic follow_page_mask code Message-ID: References: <20240327152332.950956-1-peterx@redhat.com> <20240327152332.950956-14-peterx@redhat.com> <5d9dd9a7-e544-4741-944c-469b79c2c649@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d9dd9a7-e544-4741-944c-469b79c2c649@redhat.com> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: James Houghton , Yang Shi , peterx@redhat.com, Andrew Jones , linux-mm@kvack.org, linux-riscv@lists.infradead.org, Andrea Arcangeli , Christoph Hellwig , "Aneesh Kumar K . V" , linux-arm-kernel@lists.infradead.org, Jason Gunthorpe , Axel Rasmussen , Ryan Roberts , Rik van Riel , John Hubbard , "Kirill A . Shutemov" , Vlastimil Babka , Lorenzo Stoakes , Muchun Song , linux-kernel@vger.kernel.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org, Mike Rapoport , Mike Kravetz Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Tue, Apr 02, 2024 at 05:26:28PM +0200, David Hildenbrand wrote: > > The oops trigger is at mm/gup.c:778: > > VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page); > > > > So 2M passed ok, and its failing for 32M, which is cont-pmd. I'm guessing you're trying to iterate 2M into a cont-pmd folio and ending up with an unexpected tail page? > > I assume we find the expected tail page, it's just that the check > > VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page); > > Doesn't make sense with hugetlb folios. We might have a tail page mapped in > a cont-pmd entry. As soon as we call follow_huge_pmd() on "not the first > cont-pmd entry", we trigger this check. > > Likely this sanity check must also allow for hugetlb folios. Or we should > just remove it completely. > > In the past, we wanted to make sure that we never get tail pages of THP from > PMD entries, because something would currently be broken (we don't support > THP > PMD). That was a practical limitation on my part. We have various parts of the MM which assume that pmd_page() returns a head page and until we get all of those fixed, adding support for folios larger than PMD_SIZE was only going to cause trouble for no significant wins. I agree with you we should get rid of this assertion entirely. We should fix all the places which assume that pmd_page() returns a head page, but that may take some time. As an example, filemap_map_pmd() has: if (pmd_none(*vmf->pmd) && folio_test_pmd_mappable(folio)) { struct page *page = folio_file_page(folio, start); vm_fault_t ret = do_set_pmd(vmf, page); and then do_set_pmd() has: if (page != &folio->page || folio_order(folio) != HPAGE_PMD_ORDER) return ret; so we'd simply refuse to use a PMD to map a folio larger than PMD_SIZE. There's a lot of work to be done to make this work generally (not to mention figuring out how to handle mapcount for such folios ;-). This particular case seems straightforward though. Just remove the assertion. 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7143DCD1284 for ; Tue, 2 Apr 2024 16:00:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=BTPKAtR/8nyt8Rdh1Z31elWwMnB1ZQIQ7EdIueA8SHg=; b=p2HsqL7X4lectQ F0QJTDR9ABNaWlMfuJLdWAZuNnZCsOLqNgHvBd3Wuz6c/InOTv6ZYhRILRMCra3pZcOD+hxqfVpEm UDuTzy2t3zXRcdhi0awmJ6B8FQyrJYL0Eq5t1JtPkInTmOLIMOnVRx55V7MPxfPMjvbmNi/mCQxTz qd88xdqGjqwZzD/2499MCTwmewFTaHG7BuFcEMazqSj/NseZ1F/6C17OW7jgNXTzR+7ye7fOac7+m WXaoNBsqOlB0iT8iDvwhk2iis1Xr+0/YTw6DeQj9JRdnGLYXzVJeltqc9dy103Q8LU/lwfUdRqzhQ X8HUtJVjA2YOIJUFWvFQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrgYY-0000000Bvvb-2dtI; Tue, 02 Apr 2024 16:00:14 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrgYU-0000000BvsL-3XYE; Tue, 02 Apr 2024 16:00:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=J1C2/bPg/F9WrdiBHSYL5RX039VeHvKnxuGgTbDm1H0=; b=R2IN4t4he6Ikh2eCoolYn2D1ln bR/xnpgwp5nTMZdagY0yP7uhv+3h48ujjYE5yB9UplVKqXGoqHhQDFx6Jkksdob89JG3X92Toiy2n tpdQXC31wQj8/IoO4Y+ZlLIelTem8wG91gEnWIZCkA/fbYyUxmEHFosVKc03Os3c8PAmqwJMB0gB9 hyAJUfPQ7tDBLByuN78X7TsKnwe4D8xS+YIdylZ9PDwDcfTzdsT+W4Zn0ntQp+aMaESEJLalvpLlI gcDIt6Sh0qyQ2cSKN8hyf81O7nNdTQGTV5wXPOX30EbVaeNoRNVmi6sGvQxqceiq9vEjpBDFFKqBe GnoA5Zzw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrgYO-00000003OYG-2Yps; Tue, 02 Apr 2024 16:00:04 +0000 Date: Tue, 2 Apr 2024 17:00:04 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Ryan Roberts , peterx@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yang Shi , "Kirill A . Shutemov" , Mike Kravetz , John Hubbard , Michael Ellerman , Andrew Jones , Muchun Song , linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, Christophe Leroy , Andrew Morton , Christoph Hellwig , Lorenzo Stoakes , Rik van Riel , linux-arm-kernel@lists.infradead.org, Andrea Arcangeli , "Aneesh Kumar K . V" , Vlastimil Babka , James Houghton , Jason Gunthorpe , Mike Rapoport , Axel Rasmussen Subject: Re: [PATCH v4 13/13] mm/gup: Handle hugetlb in the generic follow_page_mask code Message-ID: References: <20240327152332.950956-1-peterx@redhat.com> <20240327152332.950956-14-peterx@redhat.com> <5d9dd9a7-e544-4741-944c-469b79c2c649@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5d9dd9a7-e544-4741-944c-469b79c2c649@redhat.com> X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Apr 02, 2024 at 05:26:28PM +0200, David Hildenbrand wrote: > > The oops trigger is at mm/gup.c:778: > > VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page); > > > > So 2M passed ok, and its failing for 32M, which is cont-pmd. I'm guessing you're trying to iterate 2M into a cont-pmd folio and ending up with an unexpected tail page? > > I assume we find the expected tail page, it's just that the check > > VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page); > > Doesn't make sense with hugetlb folios. We might have a tail page mapped in > a cont-pmd entry. As soon as we call follow_huge_pmd() on "not the first > cont-pmd entry", we trigger this check. > > Likely this sanity check must also allow for hugetlb folios. Or we should > just remove it completely. > > In the past, we wanted to make sure that we never get tail pages of THP from > PMD entries, because something would currently be broken (we don't support > THP > PMD). That was a practical limitation on my part. We have various parts of the MM which assume that pmd_page() returns a head page and until we get all of those fixed, adding support for folios larger than PMD_SIZE was only going to cause trouble for no significant wins. I agree with you we should get rid of this assertion entirely. We should fix all the places which assume that pmd_page() returns a head page, but that may take some time. As an example, filemap_map_pmd() has: if (pmd_none(*vmf->pmd) && folio_test_pmd_mappable(folio)) { struct page *page = folio_file_page(folio, start); vm_fault_t ret = do_set_pmd(vmf, page); and then do_set_pmd() has: if (page != &folio->page || folio_order(folio) != HPAGE_PMD_ORDER) return ret; so we'd simply refuse to use a PMD to map a folio larger than PMD_SIZE. There's a lot of work to be done to make this work generally (not to mention figuring out how to handle mapcount for such folios ;-). This particular case seems straightforward though. Just remove the assertion. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 AF216CD1284 for ; Tue, 2 Apr 2024 16:00:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 308596B0085; Tue, 2 Apr 2024 12:00:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 291556B0088; Tue, 2 Apr 2024 12:00:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10B156B0089; Tue, 2 Apr 2024 12:00:17 -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 E1F136B0085 for ; Tue, 2 Apr 2024 12:00:16 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8BB6240A1B for ; Tue, 2 Apr 2024 16:00:16 +0000 (UTC) X-FDA: 81965053632.23.922C804 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id 804A680019 for ; Tue, 2 Apr 2024 16:00:11 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=R2IN4t4h; dmarc=none; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712073613; 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=J1C2/bPg/F9WrdiBHSYL5RX039VeHvKnxuGgTbDm1H0=; b=t9vMrVE1zG/XMKNSijyfM635IajLIK+hN/L/G5FGFbnielVGlvNuCd8XAl/V8SKFMTihYE 9/hlmTikU+qPHXnIdNB282zy72lolMgif6FEnlyahnyeyxbn3W+xvpywpzvCVqX/gdfx9D ILL7+MK/Gv3izy2dqWlKpvBuR3SQ1xQ= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=R2IN4t4h; dmarc=none; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712073613; a=rsa-sha256; cv=none; b=sJvlTb1+PWT5Q5OAN9ttIG5c+rtVbro9FJ0lRu3jO0RxaFJopkdeMKeXhFMZIq9Bvzzn2C X3mi66BAbY3+E7a2AJWuB926KumcvHSS0cgaFC9CvpkAFqJscJaxTEbWNpuOnf6zyKetp0 Klm45wDt42dGTlYMsAHV8SvXnLPnj44= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=J1C2/bPg/F9WrdiBHSYL5RX039VeHvKnxuGgTbDm1H0=; b=R2IN4t4he6Ikh2eCoolYn2D1ln bR/xnpgwp5nTMZdagY0yP7uhv+3h48ujjYE5yB9UplVKqXGoqHhQDFx6Jkksdob89JG3X92Toiy2n tpdQXC31wQj8/IoO4Y+ZlLIelTem8wG91gEnWIZCkA/fbYyUxmEHFosVKc03Os3c8PAmqwJMB0gB9 hyAJUfPQ7tDBLByuN78X7TsKnwe4D8xS+YIdylZ9PDwDcfTzdsT+W4Zn0ntQp+aMaESEJLalvpLlI gcDIt6Sh0qyQ2cSKN8hyf81O7nNdTQGTV5wXPOX30EbVaeNoRNVmi6sGvQxqceiq9vEjpBDFFKqBe GnoA5Zzw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrgYO-00000003OYG-2Yps; Tue, 02 Apr 2024 16:00:04 +0000 Date: Tue, 2 Apr 2024 17:00:04 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Ryan Roberts , peterx@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yang Shi , "Kirill A . Shutemov" , Mike Kravetz , John Hubbard , Michael Ellerman , Andrew Jones , Muchun Song , linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, Christophe Leroy , Andrew Morton , Christoph Hellwig , Lorenzo Stoakes , Rik van Riel , linux-arm-kernel@lists.infradead.org, Andrea Arcangeli , "Aneesh Kumar K . V" , Vlastimil Babka , James Houghton , Jason Gunthorpe , Mike Rapoport , Axel Rasmussen Subject: Re: [PATCH v4 13/13] mm/gup: Handle hugetlb in the generic follow_page_mask code Message-ID: References: <20240327152332.950956-1-peterx@redhat.com> <20240327152332.950956-14-peterx@redhat.com> <5d9dd9a7-e544-4741-944c-469b79c2c649@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d9dd9a7-e544-4741-944c-469b79c2c649@redhat.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 804A680019 X-Stat-Signature: 4jhcdcrm6s7szyh3ua5xbcx6f6ktas6m X-Rspam-User: X-HE-Tag: 1712073611-937372 X-HE-Meta: U2FsdGVkX1+mw4q551rhuv9wh0feJDBwIcPEA6iarPyDIRmZFbBOUJsgV1gOF5zbHzFd55OF1mepqnorF3Zgg0HZxt1PZDfMxVrrlNrszKbqWjqo0mvhMCCunsiN34epHeH+sdsliICgcybk5wL5drNgaAtJ2uCSEyQDpzyl8R6xP4LYlfLak1nH0vMTH/sd0JcwWAlEqRsgIvAETWxuyCR9Supb1DzOGzTtEt62b9s08KR+x/QIICMOZCvHtxu3nOHHuTgwwoK+rZu8zMr/5dZoRYcz57kkGbGHJ8+aeR2KGYqc0g7CLmGTCqRKFa+g1wd9gskn1JnnXlN2FRpU5OfJ/4D2nH5jQa74ly5B1IwHMxlA6vteCNA/G7BWCXT7wS6uGWWdg/SHdvf/kkuKRvGl1rl71VtIAG+7NFHhmTXR8t/685Bqj+u2YitWGSYSRL5Yp5pSBZmDhT41kG0kHcfzu+3yNlTBHPJafFRXaMQJ2hU5uy4zYWOedqGQltipDpbQlC2tuirmdzzRav6Tzegy9eOS23UgrRaQqrWSYLSUe8Xk3ruEF8D0zcWgBSbATnetf3vHsCeNzXG4DVVRc7H9HcRTSukhEhNpkHtPXArh8qfkxMaQoqzsjubVFQHSKShkz2n3hTD1p0XzAt8hySLpugqWGSmkkR1JY4NntgZQO0r+rqr5PcGg1xlrocKRrduxoT8fRQ8M+g3R/QTJMQlSRbRI127rqusyxln6Lza/+eqPk1MgFjE64HQ7fAif0SQTYjFOBXSyckCd94/OQ5YzMSofBmSHizCdHiQBmEK6iAWxnG9wYtoTXME8NTqBc97rmTVqq4O1FeOgPE9DmkKZgjc5+YFEZK4EuUgGqB6iIsUAm6IfwmyzSzRSSa9wgheaiby1afA0E8L7+JMgSOrpKfUGHxofea4YSaTfqcP33S5c3GyMJ1l0Kc9tQcdyYMn2+nqbiA9llAO/M9a zpEyvWxz wuBKEFbwp635VJiUdu+fp/XjNU/8YqO3wf5gX/TWQhvUcVkh/FiIOv+Ymg2sp2sK/qMfQ1/kbMiaMAo486ZFUG/D6zdaVykthjs0Zw8GJQpTndxh+L/czMBc8IACyKsabSAOQJ1Jr3g5edLBsMG+rTEiJba4TmzeM0FXD0WSKeSAzYl7H3yuKVQDG6MOxmsf3SZWz 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 Tue, Apr 02, 2024 at 05:26:28PM +0200, David Hildenbrand wrote: > > The oops trigger is at mm/gup.c:778: > > VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page); > > > > So 2M passed ok, and its failing for 32M, which is cont-pmd. I'm guessing you're trying to iterate 2M into a cont-pmd folio and ending up with an unexpected tail page? > > I assume we find the expected tail page, it's just that the check > > VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page); > > Doesn't make sense with hugetlb folios. We might have a tail page mapped in > a cont-pmd entry. As soon as we call follow_huge_pmd() on "not the first > cont-pmd entry", we trigger this check. > > Likely this sanity check must also allow for hugetlb folios. Or we should > just remove it completely. > > In the past, we wanted to make sure that we never get tail pages of THP from > PMD entries, because something would currently be broken (we don't support > THP > PMD). That was a practical limitation on my part. We have various parts of the MM which assume that pmd_page() returns a head page and until we get all of those fixed, adding support for folios larger than PMD_SIZE was only going to cause trouble for no significant wins. I agree with you we should get rid of this assertion entirely. We should fix all the places which assume that pmd_page() returns a head page, but that may take some time. As an example, filemap_map_pmd() has: if (pmd_none(*vmf->pmd) && folio_test_pmd_mappable(folio)) { struct page *page = folio_file_page(folio, start); vm_fault_t ret = do_set_pmd(vmf, page); and then do_set_pmd() has: if (page != &folio->page || folio_order(folio) != HPAGE_PMD_ORDER) return ret; so we'd simply refuse to use a PMD to map a folio larger than PMD_SIZE. There's a lot of work to be done to make this work generally (not to mention figuring out how to handle mapcount for such folios ;-). This particular case seems straightforward though. Just remove the assertion.