From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C3E0A398F96 for ; Thu, 4 Dec 2025 06:35:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764830139; cv=none; b=Ou0T4S1TXElwqCZINW6apcOlr6l7YOPcBtunrBaQ0pz6dWgU/2r5XM+3PRo5KBXk0QHxOoUMl6oZfvhucu7qbgMuj+n4h8BBesch3nzC+ROnhppSPdXp/s2OwFi2LWp3H8ZfZfhvE8odE/ReQ1wJnXkhPTgxgQgSOVDS018dYLs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764830139; c=relaxed/simple; bh=qq3I0S0VU3J5LrRdFM+Ka9HFuuLq+p5MynEaJa1wcxM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ATa+4vm/bRIe9FTmyWXkTdUXiEOB+LV+km9j7gtyq7XxCz1kxqacLRATgh8zHRKb9Ht/LQSPYfLQeIcQ8CLqYXaGolzDBxEgjo/YD/aND2uXRptBVcLf/mLPY6XwXbX6ICMmQG+MHZCD/G6AmVIA2X4YPdtjYge+ORJ+6an4tbI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R+ldRRBi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R+ldRRBi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D98AC116B1; Thu, 4 Dec 2025 06:35:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764830138; bh=qq3I0S0VU3J5LrRdFM+Ka9HFuuLq+p5MynEaJa1wcxM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=R+ldRRBi6aiMJPPSDQZU9HBz0zY9HhoA71Pc9+FYL+UMbj5AI8j89CjK9UWMCqU5O 1Uunf3lmic+ZUt8pEkCXfUyQQwXMVGWNrp0AfLUv/YYd2HarhxyP3pPfirJ+TdegG/ P/u4g6mTJ2sG2nBTonoGHuwwsEWXWRdfsxeEG8XVkhdvUfngY2EMcav0A67BYFWXtz +S7NaS1uT3fF0BDvECrj6CKUj7Ty16yHcv4HVgiCcitWEmb45pVUsEQTqdKzbiGJmr nz1Mr7AYPjXr0d8Ck5IPPH72P5qqpggCBKVd4MP6tekBbWBHhOsjAETnKvAQjEfWdp qGTUFJX85CPxw== Date: Thu, 4 Dec 2025 08:35:29 +0200 From: Mike Rapoport To: "David Hildenbrand (Red Hat)" Cc: Shuah Khan , akpm@linux-foundation.org, maddy@linux.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com, christophe.leroy@csgroup.eu, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, surenb@google.com, mhocko@suse.com, masahiroy@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] Revert "mm: fix MAX_FOLIO_ORDER on powerpc configs with hugetlb" Message-ID: References: <20251204023358.54107-1-skhan@linuxfoundation.org> <0b007374-1058-487c-8033-4f0d2830dc89@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0b007374-1058-487c-8033-4f0d2830dc89@kernel.org> On Thu, Dec 04, 2025 at 07:17:06AM +0100, David Hildenbrand (Red Hat) wrote: > Hi, > > On 12/4/25 03:33, Shuah Khan wrote: > > This reverts commit 39231e8d6ba7f794b566fd91ebd88c0834a23b98. > > That was supposed to fix powerpc handling though. So I think we have to > understand what is happening here. > > > > > Enabling HAVE_GIGANTIC_FOLIOS broke kernel build and git clone on two > > systems. git fetch-pack fails when cloning large repos and make hangs > > or errors out of Makefile.build with Error: 139. These failures are > > random with git clone failing after fetching 1% of the objects, and > > make hangs while compiling random files. > > On which architecture do we see these issues and with which kernel configs? > Can you share one? > > > > > The blow is is one of the git clone failures: > > > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux_6.19 > > Cloning into 'linux_6.19'... > > remote: Enumerating objects: 11173575, done. > > remote: Counting objects: 100% (785/785), done. > > remote: Compressing objects: 100% (373/373), done. > > remote: Total 11173575 (delta 534), reused 505 (delta 411), pack-reused 11172790 (from 1) > > Receiving objects: 100% (11173575/11173575), 3.00 GiB | 7.08 MiB/s, done. > > Resolving deltas: 100% (9195212/9195212), done. > > fatal: did not receive expected object 0002003e951b5057c16de5a39140abcbf6e44e50 > > fatal: fetch-pack: invalid index-pack output > > If I would have to guess, these symptoms match what we saw between commit > adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio") > and commit 5bebe8de1926 ("mm/huge_memory: Fix initialization of huge zero folio"). > > 5bebe8de1926 went into v6.18-rc7. > > Just to be sure, are you sure we were able to reproduce this issue with a > v6.18-rc7 or even v6.18 that contains 5bebe8de1926? > > Bisecting might give you wrong results, as the problems of adfb6609c680 do not > reproduce reliably. I can confirm that bisecting gives odd results between v6.18-rc5 and v6.18-rc6. I was seeing failures in some tests, bisected a few times and got a bunch of bogus commits including 3470715e5c22 ("MAINTAINERS: update David Hildenbrand's email address") :) And 5bebe8de1926 actually solved the issue for me. -- Sincerely yours, Mike.