[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e579e969-e344-8678-ca56-f933000fa7c1@arm.com>
Date: Wed, 21 Jul 2021 16:09:07 +0530
From: Anshuman Khandual <anshuman.khandual@....com>
To: Gavin Shan <gshan@...hat.com>, linux-mm@...ck.org
Cc: linux-kernel@...r.kernel.org, catalin.marinas@....com,
will@...nel.org, akpm@...ux-foundation.org, chuhu@...hat.com,
shan.gavin@...il.com,
Christophe Leroy <christophe.leroy@...roup.eu>,
Gerald Schaefer <gerald.schaefer@...ibm.com>,
Qian Cai <cai@....pw>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>
Subject: Re: [PATCH v3 01/12] mm/debug_vm_pgtable: Introduce struct
pgtable_debug_args
On 7/21/21 3:50 PM, Gavin Shan wrote:
> Hi Anshuman,
>
> 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@...hat.com>
>>> ---
>>> mm/debug_vm_pgtable.c | 197 +++++++++++++++++++++++++++++++++++++++++-
>>> 1 file changed, 196 insertions(+), 1 deletion(-)
>>>
>
> I saw you've finished the review on PATCH[v3 01/12] and PATCH[v3 02/12].
> I will wait to integrate your comments to v4 until you finish the review
> on all patches in v3 series
Yes, please do wait for the complete review and test before going for V4.
Also please add the following emails on copy next time, so that we might
have some more reviews here. Thank you.
+ Christophe Leroy <christophe.leroy@...roup.eu>
+ Gerald Schaefer <gerald.schaefer@...ibm.com>
+ Qian Cai <cai@....pw>
+ Aneesh Kumar K.V <aneesh.kumar@...ux.ibm.com>
Powered by blists - more mailing lists