Messages in this thread | | | Subject | Re: Error: freeing invalid memtype | From | "Pallipadi, Venkatesh" <> | Date | Mon, 23 Mar 2009 14:27:31 -0700 |
| |
On Mon, 2009-03-23 at 12:48 -0700, Ingo Molnar wrote: > * Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> wrote: > > > On Sat, Mar 21, 2009 at 04:05:48PM -0700, Kevin Winchester wrote: > > > Pallipadi, Venkatesh wrote: > > > > Kevin, > > > > > > > > Can you please send me the output of > > > > # cat /debug/x86/pat_memtype_list > > > > > > > > (with debugfs mounted at /debug) as soon as you login into X and also > > > > when you start seeing these errors with etracer and glxinfo. > > > > > > > > > > Here is the output before attempting to run glxinfo: > > > : : > > > : : > > > > > > Does that help track down the problem? I am about to try disabling PAT > > > in my config to see if that fixes things. > > > > > > > Can you please try the patch below and let me whether it helps. > > > > Thanks, > > Venki > > > > x86, PAT: Change vma prot in pci_mmap to reflect inherited prot > > > > While looking at the issue in the thread > > http://marc.info/?l=dri-devel&m=123606627824556&w=2 > > noticed a bug in pci PAT code and memory type setting. > > > > pci mmap code did not set the proper protection in vma, when it > > inherited protection in reserve_memtype. This bug only affects > > the case where there exists a WC mapping before X does an mmap > > with /proc or /sys pci interface. This will cause X userlevel > > mmap from /proc or /sysfs to fail on fork. > > > > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> > > Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> > > > > diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c > > index 5ead808..f234a37 100644 > > --- a/arch/x86/pci/i386.c > > +++ b/arch/x86/pci/i386.c > > @@ -319,6 +319,9 @@ int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma, > > return -EINVAL; > > } > > flags = new_flags; > > + vma->vm_page_prot = __pgprot( > > + (pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK) | > > + flags); > > If it solves the problem it will be for -stable too, right? > > It could be done a bit cleaner i think: is the ~_PAGE_CACHE_MASK > really needed? Does ->vm_page_prot ever have page frame bits set? >
Yes. This is a candidate for stable. And yes. vm_page_prot should not have cacheability bits on, so ~PAGE_CACHE_MASK can be avoided here. I had that, just wanting to be careful with and avoid further silly bugs in this code. I will test version without ~PAGE_CACHE_MASK and resend it.
Thanks, Venki
| |