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 E5722C4332F for ; Fri, 4 Nov 2022 22:23:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C45B6B0071; Fri, 4 Nov 2022 18:23:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 076CF6B0073; Fri, 4 Nov 2022 18:23:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7E116B0074; Fri, 4 Nov 2022 18:23:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D4E986B0071 for ; Fri, 4 Nov 2022 18:23:49 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A72D68159D for ; Fri, 4 Nov 2022 22:23:49 +0000 (UTC) X-FDA: 80097188178.24.CC2A6D0 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf29.hostedemail.com (Postfix) with ESMTP id BCFEA120007 for ; Fri, 4 Nov 2022 22:23:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667600628; x=1699136628; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=jyyE3UFh52oFOY3mzA8Q7BVvcDMLwn6B9acrscYPruM=; b=ajqP0/BmKmXmEJjZ94dsTAZ5lavmScEGF4BadVA2i4OrCn/qVMREEzJd KUq4dLiGY7/owFOL2tH2XyvpuA6zSzmZ/sUJsMX0/X02EZsAYJjWE/jOY j5D7syzAS50V6HYNZ0UECgrzGWsSXGfZZu6ABr/uN2z/dCCJ+HWgXUQKm g+sUYK4QKgpjdffV0bEICYFP7otRYvWIChQP9oTV0/NESY9Id7hszaKuu VRe66BFWFyCGDTDJyt3HKlVzoHr2ssMZ4NIL4Cn6/b7Bs0b6Xyq40FpAH ag0BU6KuEf/1EpUt5z1VLm1xaMNQtFVRBFnw4/u6c/lFgb+2z7ess04a0 A==; X-IronPort-AV: E=McAfee;i="6500,9779,10521"; a="293416656" X-IronPort-AV: E=Sophos;i="5.96,138,1665471600"; d="scan'208";a="293416656" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Nov 2022 15:23:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10521"; a="613223490" X-IronPort-AV: E=Sophos;i="5.96,138,1665471600"; d="scan'208";a="613223490" Received: from stinkpipe.fi.intel.com (HELO stinkbox) ([10.237.72.191]) by orsmga006.jf.intel.com with SMTP; 04 Nov 2022 15:23:41 -0700 Received: by stinkbox (sSMTP sendmail emulation); Sat, 05 Nov 2022 00:23:40 +0200 Date: Sat, 5 Nov 2022 00:23:40 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Naoya Horiguchi Cc: linux-mm@kvack.org, Andrew Morton , David Hildenbrand , Mike Kravetz , Miaohe Lin , Liu Shixin , Yang Shi , Oscar Salvador , Muchun Song , linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, regressions@lists.linux.dev, naoya.horiguchi@nec.com Subject: Re: [mm-unstable PATCH v7 2/8] mm/hugetlb: make pud_huge() and follow_huge_pud() aware of non-present pud entry Message-ID: References: <20221104155930.GA527246@ik1-406-35019.vs.sakura.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221104155930.GA527246@ik1-406-35019.vs.sakura.ne.jp> X-Patchwork-Hint: comment ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667600629; 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:dkim-signature; bh=Gyk7QbOGeCVZwReMxgWRr0/zfdScZf2xYF4JJ+zASJ8=; b=DJ64Q4qvIZpkzG2du9x0lrW+moDJixICsP/mU05usfcx5CCwVK5sLLkbEQriLHi6Z6e7xJ AVep6GIydUWppdGooBPtt5ayUFAe1vLMdZCcem6nPPs5KXe4AIjtT4cIQN0UgfnkOujOba Xvq8XgggOhxFytuakvZaNhGJSUoZQVs= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b="ajqP0/Bm"; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf29.hostedemail.com: domain of ville.syrjala@linux.intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=ville.syrjala@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667600629; a=rsa-sha256; cv=none; b=a8Bx34FNqBEwTfiemTYEZYHGPwO0fw3hMktcbaDEHbesSbIw8/xabaeUwyEfFr8SOychPR O39SNlokEewbsSKXnqnVzwvWKpPSHkFQxHXc+iIOiY0lnog6oPbIiyi3kbWMoKinN7FKAi v3A2yTLQeEoCt88YBYsSmYPbQyQIsxI= Authentication-Results: imf29.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b="ajqP0/Bm"; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf29.hostedemail.com: domain of ville.syrjala@linux.intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=ville.syrjala@linux.intel.com X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: BCFEA120007 X-Stat-Signature: sx55fbdduf4wmu6suejysk974hkzah86 X-HE-Tag: 1667600628-488238 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 Sat, Nov 05, 2022 at 12:59:30AM +0900, Naoya Horiguchi wrote: > On Wed, Nov 02, 2022 at 10:51:40PM +0200, Ville Syrjälä wrote: > > On Thu, Jul 14, 2022 at 01:24:14PM +0900, Naoya Horiguchi wrote: > > > +/* > > > + * pud_huge() returns 1 if @pud is hugetlb related entry, that is normal > > > + * hugetlb entry or non-present (migration or hwpoisoned) hugetlb entry. > > > + * Otherwise, returns 0. > > > + */ > > > int pud_huge(pud_t pud) > > > { > > > - return !!(pud_val(pud) & _PAGE_PSE); > > > + return !pud_none(pud) && > > > + (pud_val(pud) & (_PAGE_PRESENT|_PAGE_PSE)) != _PAGE_PRESENT; > > > } > > > > Hi, > > > > This causes i915 to trip a BUG_ON() on x86-32 when I start X. > > Hello, > > Thank you for finding and reporting the issue. > > x86-32 does not enable CONFIG_ARCH_HAS_GIGANTIC_PAGE, so pud_huge() is > supposed to be false on x86-32. Doing like below looks to me a fix > (reverting to the original behavior for x86-32): > diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c > index 6b3033845c6d..bf73f25aaa32 100644 > --- a/arch/x86/mm/hugetlbpage.c > +++ b/arch/x86/mm/hugetlbpage.c > @@ -37,8 +37,12 @@ int pmd_huge(pmd_t pmd) > */ > int pud_huge(pud_t pud) > { > +#ifdef CONFIG_ARCH_HAS_GIGANTIC_PAGE > return !pud_none(pud) && > (pud_val(pud) & (_PAGE_PRESENT|_PAGE_PSE)) != _PAGE_PRESENT; > +#else > + return !!(pud_val(pud) & _PAGE_PSE); // or "return 0;" ? > +#endif > } > > #ifdef CONFIG_HUGETLB_PAGE > > > Let me guess what the PUD entry was there when triggering the issue. > Assuming that the original code (before 3a194f3f8ad0) was correct, the PSE > bit in pud_val(pud) should be always cleared. So, when pud_huge() returns > true since 3a194f3f8ad0, the PRESENT bit should be clear and some other > bits (rather than PRESENT and PSE) are set so that pud_none() is false. > I'm not sure what such a non-present PUD entry does mean. pud_val()==0 when it blows up, and pud_none() is false because pgtable-nopmd.h says so with 2 level paging. And given that I just tested with PAE / 3 level paging, and sure enough it no longer blows up. So looks to me like maybe this new code just doesn't understand how the levels get folded. I might also be missing something obvious, but why is it even necessary to treat PRESENT==0+PSE==0 as a huge entry? -- Ville Syrjälä Intel