The implementation of MTRRIOC_GET_ENTRY in iarch/x86/kernel/cpu/mtrr/if.chas a comment: /* Hide entries that go above 4GB */This seems quite misguided. It certainly isn't described in thedocumentation that I've seen.

It turns out the mtrr values are transferred between the kernel anduserland in struct mtrr_gentry defined in include/asm-x86/mtrr.h.

Unfortunately, the struct field "size" is defined to be an unsignedint. This is not wide enough to represent all possible values. Itdoesn't even match the sample code in mtrr.txt: size values areconverted from text using strtoul and printed using format %lx.

But the member "base" is unsigned long and so is large enough (onx86_64). (Note: there are separate definitions of this structure for__i386__ and for !__i386__ (x86_66, I assume). But both define thesefields with the same types.)

So there are several problems:

1) .size is not large enough to hold the values it must

2) .base is not large enough on __i386__ to hold the values it must

3) the code hides entries that extend beyond 4G, even if they could be represented

4) the type of .size in mtrr.h does not match the type implied by sample code in Documentation/x86/mtrr.txt. The sample code formats .size values with %lx and decodes text representations using strtoul(3), so the type should be unsigned long.

What are the practical consequences of these problems?

I stumbled upon this problem because I was trying to write a programto manipulate MTRRs, but perhaps my application doesn't count. (Mymotivation is that the X server doesn't work on my machine due to MTRRissues.)

I think that the main (only?) user of this interface is the X server,including its drivers. X wants to change the type of the memoryaperture of the video interface.

Are there any other uses?

If X is the only important user of the interface, and it more or lessworks with the broken interface, then maybe the problem doesn't mattera lot. Apertures seem to be below 4G. I'm not sure that it doeswork - it fails on my machine.

What is to be done? Here are a bunch of possible fixes, with plusesand minuses that I can think of. Not all are mutually exclusive.

a) Document the status quo

+ can cause no new failures. Makes the kernel honest.

- the ioctl interface remains inadequate, at least in theory.

b) Fix problem (3)

+ very easy

+ I would guess that this would break no currently working programs, but I cannot be sure.