Messages in this thread |  | | | From | (Eric W. Biederman) | | Date | Thu, 05 Feb 2009 17:11:41 -0800 | | Subject | Re: 2.6.29 pat issue |
| |
Thomas Hellstrom <thellstrom@vmware.com> writes:
> Indeed, it's crucial to keep the mappings consistent, but failure to do so is a > kernel driver bug, it should never be the result of invalid user data.
It easily can be. Think of an X server mmaping frame buffers. Or other device bars.
> There are other more common kernel bugs that can be even worse and hang / crash > the system. For example using uninitialized spinlocks, writing to kfreed memory > etc. There is code in the kernel to detect these as well, but this code is > behind debug defines.
There are cpu errata on almost every cpu in existence that come into play if you have the cacheabilty attributes wrong on a page. CPUs have been known to do very weird things when you hit those errata. At the best of it you are no longer running on a deterministic machine, at the worst of it you crash the cpu.
> IMHO checking each vm_insert_pfn() for caching attribute correctness is not > something that should be enabled by default, due to the CPU overhead. Production > drivers should never violate this.
If it is a problem the implementation should become more efficient. Userspace as well as drivers can generate these mappings so even with a perfect driver you cannot guarantee that someone else does not have that area of memory mapped differently.
Eric
|  |