All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Li Xinhai" <lixinhai.lxh@gmail.com>
To: "Jason Gunthorpe" <jgg@ziepe.ca>
Cc: "Mike Kravetz" <mike.kravetz@oracle.com>,
	 "linux-mm@kvack.org" <linux-mm@kvack.org>,
	 akpm <akpm@linux-foundation.org>,
	 "Punit Agrawal" <punit.agrawal@arm.com>,
	 Longpeng <longpeng2@huawei.com>
Subject: Re: [PATCH] mm/hugetlb: avoid unnecessary check on pud and pmd entry in huge_pte_offset
Date: Fri, 24 Apr 2020 22:53:11 +0800	[thread overview]
Message-ID: <2020042422530695254845@gmail.com> (raw)
In-Reply-To: 20200424141021.GG26002@ziepe.ca

On 2020-04-24 at 22:10 Jason Gunthorpe wrote:
>On Fri, Apr 24, 2020 at 10:07:19PM +0800, Li Xinhai wrote:
>> On 2020-04-24 at 21:42 Jason Gunthorpe wrote:
>> >On Fri, Apr 24, 2020 at 09:33:40PM +0800, Li Xinhai wrote:
>> >> >
>> >> >> , so when sz == PMD_SIZE, pmd_offset() only called with a valid PUD
>> >> >> entry which point to PMD page table.
>> >> >
>> >> >But what prevents pud_huge?
>> >> >
>> >> if sz == PUD_SIZE, the 'return (pte_t*)pud' alrady end the function, which cover
>> >> pud_huge() and pud_none(), because we the mapping is for PUD_SIZE huge page.
>> >>
>> >> So, there is no possibility for pmd_offset() been called with invalid pud entry.
>> >> Below is the code I used for test which has BUG_ON, that should give more
>> >> clear idea about the semantics of code path:
>> >>
>> >> ...
>> >> pud = pud_offset(p4d, addr);
>> >> if (sz == PUD_SIZE) {
>> >> /* must be pud_huge or pud_none */
>> >> BUG_ON(!pud_huge(*pud) && !pud_none(*pud));
>> >> return (pte_t *)pud; // note that return valid pointer for pud_none() case,
>> >> // instead of NULL, that is same semantics as existing code.
>> >> }
>> >> if (!pud_present(*pud))
>> >> return NULL; // note that only return NULL in case pud not present,
>> >> // same sematics as existing code.
>> >> /* must have a valid entry and size to go further */
>> >> BUG_ON(sz != PMD_SIZE);
>> >>
>> >> pmd = pmd_offset(pud, addr);
>> >> /* must be pmd_huge or pmd_none */
>> >> BUG_ON(!pmd_huge(*pmd) && !pmd_none(*pmd));
>> >
>> >But why is !pmd_huge() ? The prior code returned null here, is that
>> >dead code? Your commit message should explain all of this..
>> >
>> let's see exising code for pmd part, the reason are in comments:
>> ...
>>         pmd = pmd_offset(pud, addr);
>>         if (sz != PMD_SIZE && pmd_none(*pmd))
>>                 return NULL; // dead code, must sz == PMD_SIZE
>>         /* hugepage or swap? */
>>         if (pmd_huge(*pmd) || !pmd_present(*pmd)) // !pmd_present() also cover pmd_none(),
>>                 return (pte_t *)pmd; // so, all possible and valid value in pmd entry will reach here.
>>
>> return NULL; // dead code; can we have (!pmd_huge() && pmd_present()) and reach here? 
>> // no, because this is a hugetlb mapping. otherwise, there is invalid value in pmd entry.
>> ...
>
>well if you are relying on the caller to not call this in wrong cases
>it would make sense to have a
>
>if (WARN_ON(!pmd_huge(*pmd)))
>    return NULL
>
>To document the assertion
> 
right, if this WARN_ON occurs, which means huge_pte_offset() been called
for a normal 4K mapping, that is a bug of caller. After inspected current code
of callers, no one tries to call it on 4K mapping.

>Jason

      reply	other threads:[~2020-04-24 14:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-23 12:49 [PATCH] mm/hugetlb: avoid unnecessary check on pud and pmd entry in huge_pte_offset Li Xinhai
2020-04-23 13:12 ` Li Xinhai
2020-04-23 18:14 ` Mike Kravetz
2020-04-23 18:38   ` Jason Gunthorpe
2020-04-24  4:07     ` Li Xinhai
2020-04-24 12:57       ` Jason Gunthorpe
2020-04-24 13:33         ` Li Xinhai
2020-04-24 13:42           ` Jason Gunthorpe
2020-04-24 14:07             ` Li Xinhai
2020-04-24 14:10               ` Jason Gunthorpe
2020-04-24 14:53                 ` Li Xinhai [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=2020042422530695254845@gmail.com \
    --to=lixinhai.lxh@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=jgg@ziepe.ca \
    --cc=linux-mm@kvack.org \
    --cc=longpeng2@huawei.com \
    --cc=mike.kravetz@oracle.com \
    --cc=punit.agrawal@arm.com \
    /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.