From: Borislav Petkov <bp@alien8.de>
To: Toshi Kani <toshi.kani@hp.com>
Cc: akpm@linux-foundation.org, hpa@zytor.com, tglx@linutronix.de,
mingo@redhat.com, linux-mm@kvack.org, x86@kernel.org,
linux-kernel@vger.kernel.org, dave.hansen@intel.com,
Elliott@hp.com, pebolle@tiscali.nl
Subject: Re: [PATCH v4 7/7] mtrr, mm, x86: Enhance MTRR checks for KVA huge page mapping
Date: Mon, 11 May 2015 23:42:44 +0200 [thread overview]
Message-ID: <20150511214244.GK15636@pd.tnic> (raw)
In-Reply-To: <1431376726.23761.471.camel@misato.fc.hp.com>
On Mon, May 11, 2015 at 02:38:46PM -0600, Toshi Kani wrote:
> MTRRs disabled is not an error case as it could be a normal
> configuration on some platforms / BIOS setups.
Normal how? PAT-only systems? Examples please...
> I clarified it in the above comment that uniform is set for any return
> value.
Hell no!
u8 mtrr_type_lookup(u64 start, u64 end, u8 *uniform)
{
...
*uniform = 1;
if (!mtrr_state_set)
return MTRR_TYPE_INVALID;
if (!(mtrr_state.enabled & MTRR_STATE_MTRR_ENABLED))
return MTRR_TYPE_INVALID;
This is wrong and the fact that I still need to persuade you about it
says a lot.
If you want to be able to state that a type is uniform even if MTRRs are
disabled, you need to define another retval which means exactly that.
Or add an inline function called mtrr_enabled() and call it in the
mtrr_type_lookup() callers.
Or whatever.
I don't want any confusing states with two return types and people
having to figure out what it exactly means and digging into the code
and scratching heads WTF is that supposed to mean.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-05-11 21:42 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-24 22:08 [PATCH v4 0/7] mtrr, mm, x86: Enhance MTRR checks for huge I/O mapping Toshi Kani
2015-03-24 22:08 ` [PATCH v4 1/7] mm, x86: Document return values of mapping funcs Toshi Kani
2015-05-05 11:19 ` Borislav Petkov
2015-05-05 13:46 ` Toshi Kani
2015-05-05 14:19 ` Borislav Petkov
2015-05-05 14:14 ` Toshi Kani
2015-03-24 22:08 ` [PATCH v4 2/7] mtrr, x86: Fix MTRR lookup to handle inclusive entry Toshi Kani
2015-05-05 17:11 ` Borislav Petkov
2015-05-05 17:32 ` Toshi Kani
2015-05-05 18:39 ` Borislav Petkov
2015-05-05 19:31 ` Toshi Kani
2015-05-05 20:09 ` Borislav Petkov
2015-05-05 20:06 ` Toshi Kani
2015-03-24 22:08 ` [PATCH v4 3/7] mtrr, x86: Remove a wrong address check in __mtrr_type_lookup() Toshi Kani
2015-05-06 10:46 ` Borislav Petkov
[not found] ` <1431332153-18566-8-git-send-email-bp@alien8.de>
2015-05-11 12:46 ` [tip:x86/mm] x86/mm/mtrr: Remove incorrect " tip-bot for Toshi Kani
2015-03-24 22:08 ` [PATCH v4 4/7] mtrr, x86: Fix MTRR state checks in mtrr_type_lookup() Toshi Kani
2015-05-06 11:47 ` Borislav Petkov
2015-05-06 15:23 ` Toshi Kani
2015-05-06 22:39 ` Borislav Petkov
2015-05-06 23:08 ` Toshi Kani
2015-03-24 22:08 ` [PATCH v4 5/7] mtrr, x86: Define MTRR_TYPE_INVALID for mtrr_type_lookup() Toshi Kani
2015-03-24 22:08 ` [PATCH v4 6/7] mtrr, x86: Clean up mtrr_type_lookup() Toshi Kani
2015-05-06 13:41 ` Borislav Petkov
2015-05-06 16:00 ` Toshi Kani
2015-05-06 22:49 ` Borislav Petkov
2015-05-06 23:42 ` Toshi Kani
2015-05-07 7:52 ` Borislav Petkov
2015-05-07 13:45 ` Toshi Kani
2015-03-24 22:08 ` [PATCH v4 7/7] mtrr, mm, x86: Enhance MTRR checks for KVA huge page mapping Toshi Kani
2015-05-09 9:08 ` Borislav Petkov
2015-05-11 19:25 ` Toshi Kani
2015-05-11 20:18 ` Borislav Petkov
2015-05-11 20:38 ` Toshi Kani
2015-05-11 21:42 ` Borislav Petkov [this message]
2015-05-11 22:09 ` Toshi Kani
2015-05-12 7:28 ` Borislav Petkov
2015-05-12 14:30 ` Toshi Kani
2015-05-12 16:31 ` Borislav Petkov
2015-05-12 16:57 ` Toshi Kani
2015-03-24 22:43 ` [PATCH v4 0/7] mtrr, mm, x86: Enhance MTRR checks for huge I/O mapping Andrew Morton
2015-04-03 6:33 ` Ingo Molnar
2015-04-03 15:22 ` Toshi Kani
2015-04-27 14:31 ` Toshi Kani
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=20150511214244.GK15636@pd.tnic \
--to=bp@alien8.de \
--cc=Elliott@hp.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=pebolle@tiscali.nl \
--cc=tglx@linutronix.de \
--cc=toshi.kani@hp.com \
--cc=x86@kernel.org \
/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