Venki Pallipadi wrote:
quoted text
> On Thu, May 08, 2008 at 02:59:31PM -0700, Venkatesh Pallipadi wrote:
>>>
>> I agree we need a better range check in place. But, the current one was not
>> really doing anything useful and actually causing the side-effect
>> regression. So, I felt not having it is better solution for now.
>>
>> Other solution is to stay with start and end range check and just ignore the
>> range check error with WC overlap in case where UC_MINUS is requested.
>>
>> Given the way MTRRs are defined, the only way to do the full range check
>> seems to be to go over page by page (from start to end), and check which
>> variable range MTTR it matches with, which is obviously very excessive. As,
>> this is not a problem in typical usage scenario.
>>

I don't believe that is true in the slightest.  You can iterate over the 
variable MTRRs and see if any part of them overlaps the target range; 
doing exhaustive enumeration is clearly bogus, especially on 64-bit 
platforms.

quoted text
> 
> Also, note that we only look for start while looking at fixed range MTRRs.
> This is not as scary as it seems. We are finding the effective memory type
> by just looking at the start of the address range. We still go through
> the PAT reserve free mechanism, once we find the effective memory type
> and that list will catch any other users with conflicting type anywhere
> in the start to end range. And we will still keep effective type consistent
> across all mappings.
> 

So what you're saying here is "it's bogus, but it doesn't really matter 
anyway?"  Why bother having it at all, then?

Seriously, if it's not unconditionally correct, then:

a. it should be *clearly* labelled a heuristic.
b. it should be *clearly* explained why having the heuristic is much 
better than not having anything.

In this case, neither of those conditions appear to be addressed.

	-hpa
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/