mtrr, x86: fix MTRR lookup to handle inclusive entry
When an MTRR entry is inclusive to a requested range, i.e. the start and
end of the request are not within the MTRR entry range but the range
contains the MTRR entry entirely, __mtrr_type_lookup() ignores such a case
because both start_state and end_state are set to zero.
This bug can cause the following issues:
1) reserve_memtype() tracks an effective memory type in case a request
type is WB (ex. /dev/mem blindly uses WB). Missing to track with its
effective type causes a subsequent request to map the same range with
the effective type to fail.
2) pud_set_huge() and pmd_set_huge() check if a requested range has any
overlap with MTRRs. Missing to detect an overlap may cause a
performance penalty or undefined behavior.
This patch fixes the bug by adding a new flag, 'inclusive', to detect the
inclusive case. This case is then handled in the same way as
(!start_state && end_state). With this fix, __mtrr_type_lookup() handles
the inclusive case properly.
Signed-off-by: Toshi Kani <toshi.kani@hp.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Robert Elliott <Elliott@hp.com> Cc: Paul Bolle <pebolle@tiscali.nl> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>