From: Thomas Gleixner <tglx@linutronix.de>
To: Pan Xinhui <xinhuix.pan@intel.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
x86@kernel.org, bp@suse.de, jgross@suse.com, mcgrof@suse.com,
decui@microsoft.com, ross.zwisler@linux.intel.com,
sfr@canb.auug.org.au, toshi.kani@hp.com,
"mnipxh@163.com" <mnipxh@163.com>
Subject: Re: [PATCH] x86/mm/pat: let level meaningful even NULL return in, lookup_address_in_pgd
Date: Fri, 17 Jul 2015 16:50:52 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.11.1507171643200.18576@nanos> (raw)
In-Reply-To: <55A5048E.3090403@intel.com>
On Tue, 14 Jul 2015, Pan Xinhui wrote:
> If pmd or pud is not set, we may set a wrong page mapping level.
No. The behaviour is simply undefined, if the return value of the
function is NULL.
So what you are trying to do is to make the level information accurate
even for the failure case.
> We know *address* belongs to *pud*, however for some reasons *pmd* is
> NULL. For example, this address has no physical pages mapped. What we
> could benefit from this patch are below:
> 1) We can walk memory range easier.
> If addressA passed to lookup_address(), and NULL returned. We can pass
> addressA + level_to_size(level) to lookup_address() in next loop.
> ...
> if (!pte) {
> /* level_to_size has not been implemented in upstream*/
> address += level_to_size(level);
> continue;
> }
This example is completely useless because we do not see how the loop
itself looks like and how that improves anything. The proper way to do
this is to post:
- the patch which changes the function
- another patch which makes use of the change
But so far I cannot see any reason why we want to change it.
> ...
> 2) keep same behavior because level is set to PG_LEVEL_4K even when pte
> is NULL.
And what's the actual benefit of #2? Keeping the same behaviour is a
requirement if you don't want to break any users of that function.
Thanks,
tglx
next prev parent reply other threads:[~2015-07-17 14:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-14 12:46 Pan Xinhui
2015-07-17 14:50 ` Thomas Gleixner [this message]
2015-07-20 3:27 ` Pan Xinhui
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=alpine.DEB.2.11.1507171643200.18576@nanos \
--to=tglx@linutronix.de \
--cc=bp@suse.de \
--cc=decui@microsoft.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@suse.com \
--cc=mingo@redhat.com \
--cc=mnipxh@163.com \
--cc=ross.zwisler@linux.intel.com \
--cc=sfr@canb.auug.org.au \
--cc=toshi.kani@hp.com \
--cc=x86@kernel.org \
--cc=xinhuix.pan@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®