From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Gavin Shan <gshan@redhat.com>, linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
will@kernel.org, akpm@linux-foundation.org, shan.gavin@gmail.com
Subject: Re: [PATCH] mm/debug_vm_pgtable: Fix corrupted PG_arch_1 by set_pmd_at()
Date: Mon, 5 Jul 2021 09:29:16 +0530 [thread overview]
Message-ID: <33cfab46-3b9b-0088-17b5-bc821c74aefb@arm.com> (raw)
In-Reply-To: <20210702103225.51448-1-gshan@redhat.com>
Hello Gavin,
On 7/2/21 4:02 PM, Gavin Shan wrote:
> There are two addresses selected: random virtual address and physical
> address corresponding to kernel symbol @start_kernel. During the PMD
> tests in pmd_advanced_tests(), the physical address is aligned down
> to the starting address of the huge page, whose size is 512MB on ARM64
> when we have 64KB base page size. After that, set_pmd_at() is called
> to populate the PMD entry. PG_arch_1, PG_dcache_clean on ARM64, is
> set to the page flags. Unforunately, the page, corresponding to the
> starting address of the huge page could be owned by buddy. It means
> PG_arch_1 can be unconditionally set to page owned by buddy.
>
> Afterwards, the page with PG_arch_1 set is fetched from buddy's free
> area list, but fails the checking. It leads to the following warning
> on ARM64:
>
> BUG: Bad page state in process memhog pfn:08000
> page:0000000015c0a628 refcount:0 mapcount:0 \
> mapping:0000000000000000 index:0x1 pfn:0x8000
> flags: 0x7ffff8000000800(arch_1|node=0|zone=0|lastcpupid=0xfffff)
> raw: 07ffff8000000800 dead000000000100 dead000000000122 0000000000000000
> raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000
> page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag(s) set
Does this problem happen right after the boot ? OR you ran some tests
and workloads to trigger this ? IIRC never seen this before on arm64.
Does this happen on other archs too ?
>
> This fixes the issue by calling flush_dcache_page() after each call
> to set_{pud, pmd, pte}_at() because PG_arch_1 isn't needed in any case.
This (arm64 specific solution) might cause some side effects on other
platforms ? The solution here needs to be generic enough. I will take
a look into this patch but probably later this week or next week.
- Anshuman
next prev parent reply other threads:[~2021-07-05 3:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 10:32 [PATCH] mm/debug_vm_pgtable: Fix corrupted PG_arch_1 by set_pmd_at() Gavin Shan
2021-07-02 18:10 ` kernel test robot
2021-07-02 18:10 ` kernel test robot
2021-07-03 0:30 ` Gavin Shan
2021-07-05 3:59 ` Anshuman Khandual [this message]
2021-07-06 5:09 ` Gavin Shan
2021-07-08 0:35 ` kernel test robot
2021-07-08 0:35 ` kernel test robot
2021-07-12 3:21 ` Anshuman Khandual
2021-07-12 3:21 ` Anshuman Khandual
2021-07-12 8:24 ` Gavin Shan
2021-07-12 8:24 ` Gavin Shan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=33cfab46-3b9b-0088-17b5-bc821c74aefb@arm.com \
--to=anshuman.khandual@arm.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=gshan@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shan.gavin@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.