[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <de7ca6bf-6a82-acba-df63-ee78eee6ee2c@oracle.com>
Date: Mon, 9 May 2022 13:02:24 -0700
From: Mike Kravetz <mike.kravetz@...cle.com>
To: Baolin Wang <baolin.wang@...ux.alibaba.com>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Muchun Song <songmuchun@...edance.com>
Cc: "dalias@...c.org" <dalias@...c.org>,
"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
"linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"James.Bottomley@...senPartnership.com"
<James.Bottomley@...senPartnership.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"paulus@...ba.org" <paulus@...ba.org>,
"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
"agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>,
"will@...nel.org" <will@...nel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"arnd@...db.de" <arnd@...db.de>,
"ysato@...rs.sourceforge.jp" <ysato@...rs.sourceforge.jp>,
"deller@....de" <deller@....de>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>,
"gor@...ux.ibm.com" <gor@...ux.ibm.com>,
"hca@...ux.ibm.com" <hca@...ux.ibm.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"tsbogend@...ha.franken.de" <tsbogend@...ha.franken.de>,
"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"svens@...ux.ibm.com" <svens@...ux.ibm.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCH v2 1/3] mm: change huge_ptep_clear_flush() to return the
original pte
On 5/9/22 01:46, Baolin Wang wrote:
>
>
> On 5/9/2022 1:46 PM, Christophe Leroy wrote:
>>
>>
>> Le 08/05/2022 à 15:09, Baolin Wang a écrit :
>>>
>>>
>>> On 5/8/2022 7:09 PM, Muchun Song wrote:
>>>> On Sun, May 08, 2022 at 05:36:39PM +0800, Baolin Wang wrote:
>>>>> It is incorrect to use ptep_clear_flush() to nuke a hugetlb page
>>>>> table when unmapping or migrating a hugetlb page, and will change
>>>>> to use huge_ptep_clear_flush() instead in the following patches.
>>>>>
>>>>> So this is a preparation patch, which changes the
>>>>> huge_ptep_clear_flush()
>>>>> to return the original pte to help to nuke a hugetlb page table.
>>>>>
>>>>> Signed-off-by: Baolin Wang <baolin.wang@...ux.alibaba.com>
>>>>> Acked-by: Mike Kravetz <mike.kravetz@...cle.com>
>>>>
>>>> Reviewed-by: Muchun Song <songmuchun@...edance.com>
>>>
>>> Thanks for reviewing.
>>>
>>>>
>>>> But one nit below:
>>>>
>>>> [...]
>>>>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>>>>> index 8605d7e..61a21af 100644
>>>>> --- a/mm/hugetlb.c
>>>>> +++ b/mm/hugetlb.c
>>>>> @@ -5342,7 +5342,7 @@ static vm_fault_t hugetlb_wp(struct mm_struct
>>>>> *mm, struct vm_area_struct *vma,
>>>>> ClearHPageRestoreReserve(new_page);
>>>>> /* Break COW or unshare */
>>>>> - huge_ptep_clear_flush(vma, haddr, ptep);
>>>>> + (void)huge_ptep_clear_flush(vma, haddr, ptep);
>>>>
>>>> Why add a "(void)" here? Is there any warning if no "(void)"?
>>>> IIUC, I think we can remove this, right?
>>>
>>> I did not meet any warning without the casting, but this is per Mike's
>>> comment[1] to make the code consistent with other functions casting to
>>> void type explicitly in hugetlb.c file.
>>>
>>> [1]
>>> https://lore.kernel.org/all/495c4ebe-a5b4-afb6-4cb0-956c1b18d0cc@oracle.com/
>>>
>>
>> As far as I understand, Mike said that you should be accompagnied with a
>> big fat comment explaining why we ignore the returned value from
>> huge_ptep_clear_flush(). >
>> By the way huge_ptep_clear_flush() is not declared 'must_check' so this
>> cast is just visual polution and should be removed.
>>
>> In the meantime the comment suggested by Mike should be added instead.
> Sorry for my misunderstanding. I just follow the explicit void casting like other places in hugetlb.c file. And I am not sure if it is useful adding some comments like below, since we did not need the original pte value in the COW case mapping with a new page, and the code is more readable already I think.
>
> Mike, could you help to clarify what useful comments would you like? and remove the explicit void casting? Thanks.
>
Sorry for the confusion.
In the original commit, it seemed odd to me that the signature of the
function was changing and there was not an associated change to the only
caller of the function. I did suggest casting to void or adding a comment.
As Christophe mentions, the cast to void is not necessary. In addition,
there really isn't a need for a comment as the calling code is not changed.
The original version of the commit without either is actually preferable.
The commit message does say this is a preparation patch and the return
value will be used in later patches.
Again, sorry for the confusion.
--
Mike Kravetz
Powered by blists - more mailing lists