From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 48BF32F5337; Thu, 10 Sep 2026 11:16:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789038971; cv=none; b=dM0M6fSNZUev71+L9uQbHsB4qTwn6zWdcU1K4h5sCztJKF6z8lFf0B54pzPx3bUpvPN6vdhmFvBmoGOBcX4E+kSSGl6Zz24ldaJgExfs2+MsR27qzk1olsdULABXneZFwda0+2Zkh+qfp0HMvGgJsVLUWttzLsllvgji89vaJJo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789038971; c=relaxed/simple; bh=hVGs1Tj7kpc4YncSVFe0orcF4b5ZciBzk2QmqTOTL1g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YEqRuyen5GTqld23mwAkY+qQaPrrmEwM2tq2HBsFd+LPQtMw6wuS3R6HYrikyB8a0o0V4GCw1GvVvvrTUYSzD8V5HZapy1F2U+i+WHGzFdu3wg5/eCf/Q1DbumndSXUJOJstGMteMCNpFSrDViL5VJX3PtUYS4gwFY+JrpeXMt0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=IpQKBy3P; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="IpQKBy3P" 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 D780C153B; Thu, 10 Sep 2026 04:16:05 -0700 (PDT) Received: from e129823.arm.com (e129823.arm.com [10.2.213.3]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 11AAE3F528; Thu, 10 Sep 2026 04:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1789038969; bh=hVGs1Tj7kpc4YncSVFe0orcF4b5ZciBzk2QmqTOTL1g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IpQKBy3P0wIZcjof1RRrgg2w+Zjdva4zQH7AyZLrz7g+fjfIlWrx5ZMYV/yR/L91q H9rkuSYiqw/m5gZVtM3RfvD7IkdW3x48VdMM1F/7nEPsKuz9CAb0nHC3Fxo76Ah0Bq DqA3PUPjOCVrQenLOMhXnt6Wf+NAeNEcd3CPRgps= Date: Thu, 10 Sep 2026 12:16:04 +0100 From: Yeoreum Yun To: "David Hildenbrand (Arm)" Cc: Yeoreum Yun , Andrew Morton , Lorenzo Stoakes , Zi Yan , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Shuah Khan , Kevin Brodsky , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/3] kselftest: mm: fix some failure of split_huge_page_test Message-ID: References: <20260907-fix_split-v5-0-822b810458bc@arm.com> <21e0a933-63b6-42b4-8cd7-df05b0c9acfc@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <21e0a933-63b6-42b4-8cd7-df05b0c9acfc@kernel.org> On Thu, Sep 10, 2026 at 12:45:39PM +0200, David Hildenbrand (Arm) wrote: > On 9/10/26 12:31, Yeoreum Yun wrote: > >> On 9/7/26 10:19, Yeoreum Yun wrote: > >>> split_huge_page_test can fail for the following reasons: > >>> > >>> 1. During the test, khugepaged may collapse previously split pages again, > >>> causing intermittent failures. > >>> > >>> 2. Since glibc commit 321e1fc73f (“malloc: Enable 2MB THP by default on AArch64”), > >>> glibc may call madvise(MADV_HUGEPAGE) for sufficiently large allocations > >>> made by memalign(). The underlying VMA may start at a different address > >>> from the aligned address returned by memalign(). Moreover, a subsequent > >>> madvise(MADV_HUGEPAGE) call does not split the VMA because it already > >>> has the same advice. > >>> > >>> This causes the test to fail because the check_huge_xxx() helpers > >>> incorrectly require the address returned by memalign() to match the > >>> VMA start address reported in /proc/self/smaps. > >>> > >>> Address these issues by applying MADV_NOHUGEPAGE after faulting in the > >>> huge page, preventing khugepaged from collapsing it again, and instead of > >>> relying on /proc/self/smaps, use /proc/self/pagemap and > >>> /proc/kpageflags to detect huge-page mappings and large folios: > >>> > >>> 1. If hpage_size == pmd_pagesize, check PAGE_IS_HUGE instead of > >>> using check_large_folios(), since only the mapping type matters. > >>> This identifies PMD-mapped huge pages. > >>> 2. Otherwise, use check_large_folios() to detect large folios. This > >>> covers mTHP cases. > >>> 3. Check the folio flags according to the type of huge page. > >>> > >>> Also, current usage of memalign() would result memory area may > >>> unexpectedly merge with an adjacent VMA, causing tests > >>> that inspect it through /proc/self/smaps to fail. > >> I'm not particularly happy about this. > >> > >> Relying on VMA merging details rather hints that we shouldn't be using smaps to > >> query some stats/properties. > >> > >> Which exact things are test querying through /proc/self/smaps? Could we convert > >> the code to just query that stuff through different interfaces? > > > > Well, users currently for using /proc/self/smaps are for check vm-flags: > > - guard-regions where using check_vmflags_guard() > > - pfnmap test where uses check_vmflag_pfnmap() > > Most vm-flags should not be an issue when it comes to merging. The only > exception are vmflags that do not prevent VMA merging. > > So it's VM_SOFTDIRTY and VM_MAYBE_GUARD. And I agree that for guard-regions.c we > likely have to care such that we don't merge by accident with other VMAs (guard > regions). > > But that's independent of memalign. > > ptr = mmap_(self, variant, NULL, 10 * page_size, PROT_READ | PROT_WRITE, 0, 0); > ASSERT_FALSE(check_vmflag_guard(ptr)); > > could be problematic on its own (unlikely but possible). Yes. That's why I'm think it would be good to use alloc_isolated_mem() in case of ANON mapping for this case. > > For other flags, you really only have to find the smaps area that covers the > given address and look at the vm-flags. > > Or am I missing something important? > > (merging vnas with VM_PFNMAP is impossible right now IIRC) No. what I want to say including the patch #3 is for the above case where you point out -- ASSERT_FALSE(check_vmflag_guard(ptr)). Since we don't have any interface to check vm_flags execpt smap and for memory mmaped with anon would have a chance to merge, We need something to replace memalign() with preventing unexpected VMA merge. (But I forgot to change the those case in guard test case). -- Sincerely, Yeoreum Yun