From: jane.chu@oracle.com
To: David Hildenbrand <david@redhat.com>,
harry.yoo@oracle.com, osalvador@suse.de, liushixin2@huawei.com,
muchun.song@linux.dev, akpm@linux-foundation.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/hugetlb: fix copy_hugetlb_page_range() to use ->pt_share_count
Date: Mon, 15 Sep 2025 09:51:33 -0700 [thread overview]
Message-ID: <3bbfa5ff-cecb-45f8-b1ef-e380cba155a6@oracle.com> (raw)
In-Reply-To: <eb6e18c0-533f-4e77-a56f-60ab8cacc369@redhat.com>
On 9/12/2025 12:31 AM, David Hildenbrand wrote:
> On 11.09.25 21:54, jane.chu@oracle.com wrote:
>>
>> On 9/9/2025 11:45 PM, David Hildenbrand wrote:
>> [..]
>>>> - /*
>>>> - * If the pagetables are shared don't copy or take references.
>>>> - *
>>>> - * dst_pte == src_pte is the common case of src/dest sharing.
>>>> - * However, src could have 'unshared' and dst shares with
>>>> - * another vma. So page_count of ptep page is checked instead
>>>> - * to reliably determine whether pte is shared.
>>>> - */
>>>> - if (page_count(virt_to_page(dst_pte)) > 1) {
>>>> +#ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING
>>>> + /* If the pagetables are shared don't copy or take
>>>> references. */
>>>
>>> Why remove so much of the original comment?
>>
>> Because, this part of checking has already advanced from the "dst_pte ==
>> src_pte" to "page_count() > 1" to ->pt_share_count > 0, it seems cleaner
>> to just keep an one liner comment.
>> That said, if you feel the comments should be kept, I'd be happy to
>> restore them with a bit revision.
>
> Well, the comment explains why checking the pte pointers is insufficient
> and why there is a corner case where the pointers differ but we still
> want to unshare. :)
>
> But yeah, I agree that reading the code it's clear: if dst is already
> shared, just don't do anything.
>
> I would probably rephrase the comment to something simpler like
>
> "/* If the pagetables are shared, there is nothing to do. */
>
> If you resend, please add a comment to the patch description like "While
> at it, simplify the comment, the details are not actually relevant
> anymore".
>
Will do, thanks!
-jane
prev parent reply other threads:[~2025-09-15 16:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 18:43 [PATCH] mm/hugetlb: fix copy_hugetlb_page_range() to use ->pt_share_count Jane Chu
2025-09-10 1:14 ` Harry Yoo
2025-09-10 19:23 ` jane.chu
2025-09-10 6:45 ` David Hildenbrand
2025-09-11 19:54 ` jane.chu
2025-09-12 7:31 ` David Hildenbrand
2025-09-15 16:51 ` jane.chu [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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3bbfa5ff-cecb-45f8-b1ef-e380cba155a6@oracle.com \
--to=jane.chu@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=harry.yoo@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liushixin2@huawei.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.