archive mirror
 help / color / mirror / Atom feed
From: Anshuman Khandual <>
To: Gavin Shan <>,
Subject: Re: [PATCH 00/12] mm/debug_vm_pgtable: Enhancements
Date: Sun, 18 Jul 2021 12:06:22 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 7/15/21 10:47 AM, Gavin Shan wrote:
> Hi Anshuman,
> On 7/14/21 3:26 PM, Anshuman Khandual wrote:
>> On 7/13/21 6:50 AM, Gavin Shan wrote:
>>> On 7/12/21 2:14 PM, Anshuman Khandual wrote:
>>>> Though I have not jumped into the details for all individual
>>>> patches here but still have some high level questions below.
>>>> On 7/6/21 11:47 AM, Gavin Shan wrote:
>>>>> There are couple of issues with current implementations and this series
>>>>> tries to resolve the issues:
>>>>>     (a) All needed information are scattered in variables, passed to various
>>>>>         test functions. The code is organized in pretty much relaxed fashion.
>>>> All these variables are first prepared in debug_vm_pgtable(), before
>>>> getting passed into respective individual test functions. Also these
>>>> test functions receive only the required number of variables not all.
>>>> Adding a structure that captures all test parameters at once before
>>>> passing them down will be unnecessary. I am still wondering what will
>>>> be the real benefit of this large code churn ?
>>> Thanks for your review. There are couple of reasons to have "struct vm_pgtable_debug".
>>> (1) With the struct, the old and new implementation can coexist. In this way,
>>>      the patches in this series can be stacked up easily.
>> Makes sense.
>>> (2) I think passing single struct to individual test functions improves the
>>>      code readability. Besides, it also makes the empty stubs simplified.
>> Empty stub simplified - reduced argument set in the empty stubs ?
> Yes.
>>> (3) The code can be extended easily if we need in future.
>> Agreed.
>>>>>     (b) The page isn't allocated from buddy during page table entry modifying
>>>>>         tests. The page can be invalid, conflicting to the implementations
>>>>>         of set_{pud, pmd, pte}_at() on ARM64. The target page is accessed
>>>>>         so that the iCache can be flushed when execution permission is given
>>>>>         on ARM64. Besides, the target page can be unmapped and access to
>>>>>         it causes kernel crash.
>>>> Using 'start_kernel' based method for struct page usage, enabled this
>>>> test to run on platforms which might not have enough memory required
>>>> for various individual test functions. This method is not a problem for
>>>> tests that just need an aligned pfn (which creates a page table entry)
>>>> not a real struct page.
>>>> But not allocating and owning the struct page might be problematic for
>>>> tests that expect a real struct page and transform its state via set_
>>>> {pud, pmd, pte}_at() functions as reported here.
>>> Yeah, I totally agree. The series follows what you explained: Except the
>>> test cases where set_{pud, pmd, pte}_at() is used, the allocated page
>>> is used. For other test cases, 'start_kernel' based PFN is used as before.
>>>>> "struct vm_pgtable_debug" is introduced to address issue (a). For issue
>>>>> (b), the used page is allocated from buddy in page table entry modifying
>>>>> tests. The corresponding tets will be skipped if we fail to allocate the
>>>>> (huge) page. For other test cases, the original page around to kernel
>>>>> symbol (@start_kernel) is still used.
>>>> For all basic pfn requiring tests, existing 'start_kernel' based method
>>>> should continue but allocate a struct page for other tests which change
>>>> the passed struct page. Skipping the tests when allocation fails is the
>>>> right thing to do.
>>> Yes, it's exactly what this series does. Hope you can jump into the details
>>> when you get a chance :)
>> I have already started looking into the series. But still wondering if
>> the huge page memory allocation change and the arm64 specific page fix
>> should be completed first, before getting into the new structure based
>> arguments (in a separate series). Although the end result would still
>> remain the same, the transition there would be better I guess. Do you
>> see any challenges in achieving that ?
> Thanks for your time to review in details. As I can understand, the reason
> to have the fix for easy backporting to stable-kernel and I didn't do that
> because of couple of facts: (1) The changes included in this series only
> affects only one source file, so backporting the whole series isn't hard.
> (2) There will be more redundant code if we include the fix before switching
> to "struct vm_pgtable_debug". It's unnecessary.


> So lets keep the patch layout we had if you agree. Actually, the issues are
> found during the testing with RHEL downstream kernel. Once it's settled down,
> I will backport the whole series to RHEL downstream kernel.

Okay, then lets keep this proposed layout and address the issues here.

- Anshuman

      reply	other threads:[~2021-07-18  6:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-06  6:17 Gavin Shan
2021-07-06  6:17 ` [PATCH 01/12] mm/debug_vm_pgtable: Introduce struct vm_pgtable_debug Gavin Shan
2021-07-14  6:24   ` Anshuman Khandual
2021-07-19  5:39     ` Gavin Shan
2021-07-20  7:02       ` Anshuman Khandual
2021-07-20 23:07         ` Gavin Shan
2021-07-21  4:20           ` Anshuman Khandual
2021-07-06  6:17 ` [PATCH 02/12] mm/debug_vm_pgtable: Use struct vm_pgtable_debug in basic tests Gavin Shan
2021-07-06  6:17 ` [PATCH 03/12] mm/debug_vm_pgtable: Use struct vm_pgtable_debug in leaf and savewrite tests Gavin Shan
2021-07-06  6:17 ` [PATCH 04/12] mm/debug_vm_pgtable: Use struct vm_pgtable_debug in protnone and devmap tests Gavin Shan
2021-07-06  6:17 ` [PATCH 05/12] mm/vm_debug_pgtable: Use struct vm_pgtable_debug in soft_dirty and swap tests Gavin Shan
2021-07-06  6:17 ` [PATCH 06/12] mm/debug_vm_pgtable: Use struct vm_pgtable_debug in migration and thp tests Gavin Shan
2021-07-06  6:17 ` [PATCH 07/12] mm/debug_vm_pgtable: Use struct vm_pgtable_debug in PTE modifying tests Gavin Shan
2021-07-06  6:17 ` [PATCH 08/12] mm/debug_vm_pgtable: Use struct vm_pgtable_debug in PMD " Gavin Shan
2021-07-06  6:17 ` [PATCH 09/12] mm/vm_debug_pgtable: Use struct vm_pgtable_debug in PUD " Gavin Shan
2021-07-06  6:17 ` [PATCH 10/12] mm/debug_vm_pgtable: Use struct vm_pgtable_debug in PGD and P4D " Gavin Shan
2021-07-06  6:17 ` [PATCH 11/12] mm/debug_vm_pgtable: Remove unused code Gavin Shan
2021-07-06  6:17 ` [PATCH 12/12] mm/debug_vm_pgtable: Fix corrupted page flag Gavin Shan
2021-07-12  4:14 ` [PATCH 00/12] mm/debug_vm_pgtable: Enhancements Anshuman Khandual
2021-07-13  1:20   ` Gavin Shan
2021-07-14  5:26     ` Anshuman Khandual
2021-07-15  5:17       ` Gavin Shan
2021-07-18  6:36         ` Anshuman Khandual [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 00/12] mm/debug_vm_pgtable: Enhancements' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).