Hi Anshuman,
On 7/22/21 5:08 PM, Anshuman Khandual wrote:
On 7/22/21 11:53 AM, Gavin Shan wrote:
On 7/22/21 2:41 PM, Anshuman Khandual wrote:
On 7/21/21 3:50 PM, Gavin Shan wrote:
On 7/21/21 3:44 PM, Anshuman Khandual wrote:
On 7/19/21 6:36 PM, Gavin Shan wrote:
In debug_vm_pgtable(), there are many local variables introduced to
track the needed information and they are passed to the functions for
various test cases. It'd better to introduce a struct as place holder
for these information. With it, what the functions for various test
cases need is the struct, to simplify the code. It also makes code
easier to be maintained.
Besides, set_xxx_at() could access the data on the corresponding pages
in the page table modifying tests. So the accessed pages in the tests
should have been allocated from buddy. Otherwise, we're accessing pages
that aren't owned by us. This causes issues like page flag corruption.
This introduces "struct pgtable_debug_args". The struct is initialized
and destroyed, but the information in the struct isn't used yet. They
will be used in subsequent patches.
Signed-off-by: Gavin Shan <gshan@xxxxxxxxxx>
---
mm/debug_vm_pgtable.c | 197 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 196 insertions(+), 1 deletion(-)
[...]
IIRC it is also not guaranteed that PMD_SHIFT <= (MAX_ORDER - 1). Hence
this same scheme should be followed for PMD level allocation as well.
In theory, it's possible to have PMD_SHIFT <= (MAX_ORDER - 1) with misconfigured
kernel. I will apply the similar logic to PMD huge page in v4.
[... The code to release the PUD huge page needs changes based on @args->is_contiguous_pud_page]
Right, a flag would be needed to call the appropriate free function.
Yes. We need two falgs for PUD and PMD huge pages separately.
A single flag should be enough, the order would be dependent on
whether args->pud_pfn or args->pmd_pfn is valid.
Yes, it's correct that one flag is enough as we're sharing the PUD
or PMD huge page.
Thanks,
Gavin
