Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Date:   Thu, 19 Oct 2023 11:15:32 +0900
From:   Sergey Senozhatsky <senozhatsky@chromium.org>
To:     Mike Kravetz <mike.kravetz@oracle.com>
Cc:     Sergey Senozhatsky <senozhatsky@chromium.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org,
        Muchun Song <songmuchun@bytedance.com>,
        Joao Martins <joao.m.martins@oracle.com>,
        Konrad Dybcio <konradybcio@kernel.org>,
        Oscar Salvador <osalvador@suse.de>,
        David Hildenbrand <david@redhat.com>,
        Miaohe Lin <linmiaohe@huawei.com>,
        David Rientjes <rientjes@google.com>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        Naoya Horiguchi <naoya.horiguchi@linux.dev>,
        Barry Song <21cnbao@gmail.com>, Michal Hocko <mhocko@suse.com>,
        Matthew Wilcox <willy@infradead.org>,
        Xiongchun Duan <duanxiongchun@bytedance.com>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Bisected: [PATCH v7 2/8] hugetlb: restructure pool allocations
Message-ID: <20231019021532.GA14965@google.com>
References: <20231006032012.296473-1-mike.kravetz@oracle.com>
 <20231006032012.296473-3-mike.kravetz@oracle.com>
 <20231011064756.GB2866435@google.com>
 <20231018224422.GC5181@monkey>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231018224422.GC5181@monkey>
Precedence: bulk

On (23/10/18 15:44), Mike Kravetz wrote:
> Hi Sergey,
> 
> Sorry for the delay.  Not ignoring your report but chasing this in
> another thread.

Hi Mike, no worries.

> https://lore.kernel.org/linux-mm/20231018222003.GA21776@monkey/

Oh, interesting.
I just read the article the other day about some of unexpected optimizations
that clang can do [1].

Setting h to NULL seems to be fixing the problem for me.

> Quick question.
> Are you using LLVM/clang in your builds?

Yes, clang 14.0.6
The kernel compiled with gcc does not BUG_ON().

> My guess is that you are hitting the same issue.  That BUG at mm/hugetlb.c:3180
> should not be checked/executed unless you allocate gigantic hugetlb pages on
> the kernel command line.  Suspect you are not doing this, and loop code is
> being run when it should not.

Looks very similar indeed.

[1] https://research.swtch.com/ub