[PATCH -next v4 3/4] arm64: mm: add support for page table check
Tong Tiangen
tongtiangen at huawei.com
Tue Apr 19 01:52:41 PDT 2022
在 2022/4/19 15:10, Anshuman Khandual 写道:
>
>
> On 4/18/22 21:17, Tong Tiangen wrote:
>>
>>
>> 在 2022/4/18 17:28, Anshuman Khandual 写道:
>>> On 4/18/22 09:14, Tong Tiangen wrote:
>>>> From: Kefeng Wang <wangkefeng.wang at huawei.com>
[...]
>>>
>>> Could you explain what was expected during pmdp_collapse_flush() which when
>>> failed, triggered this BUG_ON() ? This counter seems to be page table check
>>> specific, could it just go wrong ? I have not looked into the details about
>>> page table check mechanism.
>>>
>>> - Anshuman
>>> .
>>
>> Hi Anshuman:
>>
>> Thanks for your job.
>>
>> Let me briefly explain the principle of page table check(PTC).
>>
>> PTC introduces the following struct for page mapping type count:
>> struct page_table_check {
>> atomic_t anon_map_count;
>> atomic_t file_map_count;
>> };
>> This structure can be obtained by "lookup_page_ext(page)"
>
>
> Right.
>
>>
>> When page table entries are set(pud/pmd/pte), page_table_check_set() is called to increase the page mapping count, Also check for errors (eg:if a page is used for anonymous mapping, then the page cannot be used for file mapping at the same time).
>>
>> When page table entries are clear(pud/pmd/pte), page_table_check_clear() is called to decrease the page mapping count, Also check for errors.
>>
>> The error check rules are described in the following documents: Documentation/vm/page_table_check.rst
>
> Snippet from that document.
>
> +-------------------+-------------------+-------------------+------------------+
> | Current Mapping | New mapping | Permissions | Rule |
> +===================+===================+===================+==================+
> | Anonymous | Anonymous | Read | Allow |
> +-------------------+-------------------+-------------------+------------------+
> | Anonymous | Anonymous | Read / Write | Prohibit |
> +-------------------+-------------------+-------------------+------------------+
> | Anonymous | Named | Any | Prohibit |
> +-------------------+-------------------+-------------------+------------------+
> | Named | Anonymous | Any | Prohibit |
> +-------------------+-------------------+-------------------+------------------+
> | Named | Named | Any | Allow |
> +-------------------+-------------------+-------------------+------------------+
>
> Does 'Named' refer to file mapping ? Also what does 'Prohibit' imply here ? The
> check will call out a BUG_ON() in such cases ?
Right, Named means file mapping, Prohibit here trigger BUG_ON.
>
> page_table_check_clear()
> {
>
> if (anon) {
> BUG_ON(atomic_read(&ptc->file_map_count));
> BUG_ON(atomic_dec_return(&ptc->anon_map_count) < 0);
> } else {
> BUG_ON(atomic_read(&ptc->anon_map_count));
> BUG_ON(atomic_dec_return(&ptc->file_map_count) < 0);
> }
> }
>
> So in the clear path, there are two checks
>
> - If the current mapping is Anon, file_map_count cannot be positive and other way
> - Decrement the applicable counter ensuring that it does not turn negative
>
> page_table_check_set()
> {
> if (anon) {
> BUG_ON(atomic_read(&ptc->file_map_count));
> BUG_ON(atomic_inc_return(&ptc->anon_map_count) > 1 && rw);
> } else {
> BUG_ON(atomic_read(&ptc->anon_map_count));
> BUG_ON(atomic_inc_return(&ptc->file_map_count) < 0);
> }
> }
>
> So in the set path, there are two checks
>
> - If the current mapping is anon, file_map_count cannot be positive and other way
> - Anon mapping cannot be RW if the page has been mapped more than once
> - But then why check for negative values for file_map_count after increment ?
Check for negative after increment is logically OK and <=0 should be
more reasonable.
>
> Is there any other checks, which this test ensures, that I might be missing ?
The following checks are performed when page table entry are
allocated/released:
__page_table_check_zero()
{
BUG_ON(atomic_read(&ptc->anon_map_count));
BUG_ON(atomic_read(&ptc->file_map_count));
}
>
>>
>> The setting and clearing of page table entries are symmetrical.
>
> This assumption should be true for any user accessible mapping, for this test to work ?
Right, if not, here is BUG_ON.
However, as Pasha said:
"this being new on ARM64, it is possible that the bug is in
PTC/khugepaged itself."
>
> Also why PUD_PAGE_SIZE/PMD_PAGE_SIZE are being used here instead of directly using
> generic macros such as PUD_SIZE/PMD_SIZE ? Is there a specific reason ?
I did code optimization for this, in patch 1/4 of this patchset:
+#ifndef PMD_PAGE_SIZE
+#define PMD_PAGE_SIZE PMD_SIZE
+#endif
+
+#ifndef PUD_PAGE_SIZE
+#define PUD_PAGE_SIZE PUD_SIZE
+#endif
Thank you.
Tong.
>
>>
>> Here __page_table_check_pmd_clear() trigger BUGON which indicates that the pmd entry file mapping count has become negative.
>>
>> I guess if PTC didn't detect this exception, would there have been any problems?
>
> I am looking into this, not sure for now.
> .
More information about the linux-riscv
mailing list