Re: Patch [1/1] minor bugfix in 2.6.26/arch/x86/mm/pat.c - caused problems in mmap() of /dev/mem character file

[Arjan van de Ven <arjan@infradead.org>]

On Sun, 20 Jul 2008 21:20:46 +0530
"V.Radhakrishnan" <rk@atr-labs.com> wrote:
> 
> It so happened that all my 17 students had working code with 2.6.25
> and I, the instructor, had the kernel 2.6.26 crash in front of them !
> 
> So I started tracing the call and found the 'bug' and 'fixed it'.

to get the old behavior, just disable PAT..

> 
> I agree with you 100% that my patch does not solve the problem, but
> is a quick fix approach to the next release. The PAT related access
> issue is valid. However, I humbly submit that memory access is a
> policy issue and perhaps should not be tinkered with thru code. 

it's not policy, it's correctness. We don't allow root to open a file
on a cdrom for write and then write to it.. even though denying root
would equally be policy, right? (it's not)

> 
> If you provide the root, access to /dev/mem, I don't think it should
> be a problem, since in any case, all others are denied access.

this assertion is not correct; the device driver, the pagecache etc etc
will still use the page for whatever they were using it for.
> Also,
> theoretically, if you access RAM for Read Only, why should there be a
> triple fault ? 

yes.
If you access it as cachable from /dev/mem, but the actual owner of the
memory was using it uncached, that can tripple fault the cpu (again
depending on model etc). If you access it uncachable from /dev/mem, but
the owner was using it cached... likewise. (and on some systems, the CPU
is fine but the chipset/memory controller are not)

On x86 you're not supposed to mix cached and uncached. And PAT enforces
this for all cases where there's an owner.. but for /dev/mem there's no
such thing.


-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org