Searched hist:fba88ede6a312705e147860c45ed9b3c3d9c6f85 (Results 1 – 2 of 2) sorted by relevance
/linux/arch/riscv/include/asm/ |
H A D | pgtable-bits.h | diff fba88ede6a312705e147860c45ed9b3c3d9c6f85 Tue Nov 23 15:06:37 CET 2021 Nanyong Sun <sunnanyong@huawei.com> riscv/mm: Adjust PAGE_PROT_NONE to comply with THP semantics
This is a preparation for enabling THP migration. As the commit b65399f6111b("arm64/mm: Change THP helpers to comply with generic MM semantics") mentioned, pmd_present() and pmd_trans_huge() are expected to behave in the following manner: ------------------------------------------------------------------------- | PMD states | pmd_present | pmd_trans_huge | ------------------------------------------------------------------------- | Mapped | Yes | Yes | ------------------------------------------------------------------------- | Splitting | Yes | Yes | ------------------------------------------------------------------------- | Migration/Swap | No | No | -------------------------------------------------------------------------
At present the PROT_NONE bit reuses the READ bit could not comply with above semantics with two problems: 1. When splitting a PMD THP, PMD is first invalidated with pmdp_invalidate()->pmd_mkinvalid(), which clears the PRESENT bit and PROT_NONE bit/READ bit, if the PMD is read-only, then the PAGE_LEAF property is also cleared, which results in pmd_present() return false. 2. When migrating, the swap entry only clear the PRESENT bit and PROT_NONE bit/READ bit, the W/X bit may be set, so _PAGE_LEAF may be true which results in pmd_present() return true.
Solution: Adjust PROT_NONE bit from READ to GLOBAL bit can satisfy the above rules: 1. GLOBAL bit has no other meanings, not like the R/W/X bit, which is also relative with _PAGE_LEAF property. 2. GLOBAL bit is at bit 5, making swap entry start from bit 6, bit 0-5 are zero, which means the PRESENT, PROT_NONE, and PAGE_LEAF are all false, then the pmd_present() and pmd_trans_huge() return false when in migration/swap.
Signed-off-by: Nanyong Sun <sunnanyong@huawei.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
|
H A D | pgtable.h | diff fba88ede6a312705e147860c45ed9b3c3d9c6f85 Tue Nov 23 15:06:37 CET 2021 Nanyong Sun <sunnanyong@huawei.com> riscv/mm: Adjust PAGE_PROT_NONE to comply with THP semantics
This is a preparation for enabling THP migration. As the commit b65399f6111b("arm64/mm: Change THP helpers to comply with generic MM semantics") mentioned, pmd_present() and pmd_trans_huge() are expected to behave in the following manner: ------------------------------------------------------------------------- | PMD states | pmd_present | pmd_trans_huge | ------------------------------------------------------------------------- | Mapped | Yes | Yes | ------------------------------------------------------------------------- | Splitting | Yes | Yes | ------------------------------------------------------------------------- | Migration/Swap | No | No | -------------------------------------------------------------------------
At present the PROT_NONE bit reuses the READ bit could not comply with above semantics with two problems: 1. When splitting a PMD THP, PMD is first invalidated with pmdp_invalidate()->pmd_mkinvalid(), which clears the PRESENT bit and PROT_NONE bit/READ bit, if the PMD is read-only, then the PAGE_LEAF property is also cleared, which results in pmd_present() return false. 2. When migrating, the swap entry only clear the PRESENT bit and PROT_NONE bit/READ bit, the W/X bit may be set, so _PAGE_LEAF may be true which results in pmd_present() return true.
Solution: Adjust PROT_NONE bit from READ to GLOBAL bit can satisfy the above rules: 1. GLOBAL bit has no other meanings, not like the R/W/X bit, which is also relative with _PAGE_LEAF property. 2. GLOBAL bit is at bit 5, making swap entry start from bit 6, bit 0-5 are zero, which means the PRESENT, PROT_NONE, and PAGE_LEAF are all false, then the pmd_present() and pmd_trans_huge() return false when in migration/swap.
Signed-off-by: Nanyong Sun <sunnanyong@huawei.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
|