[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150511214244.GK15636@pd.tnic>
Date: Mon, 11 May 2015 23:42:44 +0200
From: Borislav Petkov <bp@...en8.de>
To: Toshi Kani <toshi.kani@...com>
Cc: akpm@...ux-foundation.org, hpa@...or.com, tglx@...utronix.de,
mingo@...hat.com, linux-mm@...ck.org, x86@...nel.org,
linux-kernel@...r.kernel.org, dave.hansen@...el.com,
Elliott@...com, pebolle@...cali.nl
Subject: Re: [PATCH v4 7/7] mtrr, mm, x86: Enhance MTRR checks for KVA huge
page mapping
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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists