Messages in this thread | | | Subject | RE: [git pull] x86 PAT changes | Date | Sat, 26 Apr 2008 09:54:23 -0700 | From | "Pallipadi, Venkatesh" <> |
| |
>-----Original Message----- >From: linux-kernel-owner@vger.kernel.org >[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Ingo Molnar >Sent: Saturday, April 26, 2008 1:56 AM >To: Linus Torvalds >Cc: H. Peter Anvin; linux-kernel@vger.kernel.org; Andrew >Morton; Thomas Gleixner >Subject: Re: [git pull] x86 PAT changes > > >* Linus Torvalds <torvalds@linux-foundation.org> wrote: > >> On Fri, 25 Apr 2008, H. Peter Anvin wrote: >> > >> > The problem is that that can create cached/uncached aliases, which >> > can cause some processors to lock up (especially AMD is known to >> > have a lot of errata in this area.) >> >> Umm.. I don't think you understand. Right now, NONPROMISC_DEVMEM >> doesn't just disable mmap() on /dev/mem, it disables totally regular >> reads and writes too. That seems pretty damn excessive. >> >> If it was just mmap(), I don't think it would matter much. I don't >> think we traditionally even supported mmap() on real RAM >(because the >> page counting would get confused), and that actually got supported >> only thanks to VM changes that made it possible. >> >> But read/write has always been supported, and shouldn't cause any >> cached/uncached aliases! > >You are right, there should be no architectural need to make PAT >dependent on nonpromisc-devmem, and thus the patch below >should be safe. >
Agreed that NONPROMISC_DEVMEM is not really needed for read/write. But, we will still need it for /dev/mem.
The problem with /dev/mem maps of RAM is situation like this: 1) drivers does vmalloc(), followed by set_memory_uc. 2) User does a /dev/mem map of that vmalloced physical address. User will get a UC mapping for /dev/mem. 3) driver changes the memory to set_memory_wb and frees the memory. 4) user mapping for this address is still UC which will lead to aliasing.
Read/write is ok, as they will just use __va for RAM to access and that will always be consistent.
Thanks, Venki
| |