lkml.org 
[lkml]   [2007]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] mm: recheck lock rlim after f_op->mmap() method
On Wed, 11 Jul 2007, Christoph Hellwig wrote:
> On Wed, Jul 11, 2007 at 02:12:45PM +0400, Dmitry Monakhov wrote:
> > > > Or would this simpler patch be the right one? I suspect the
> > > > mspec driver only says VM_LOCKED because of a deep-seated but
> > > > irrational fear that its pages might fall into reclaim.

I was perhaps too unkind: that fear was not irrational in 2.4,
when reclaim scanned vmas; but in 2.6, pages have to be on one
of reclaim's LRUs to fall vulnerable to it.

> > >
> > > Looks good. We probably should add a debug check to do_mmap_pgoff
> > > so that ->mmap methods don't change flags that are not for drivers.

We could indeed, though I'd rather not jump into that: something
to do when we tidy up those driver mmaps (something I promised to
do 18 months ago?), there's a lot of pointless flag setting.

> > As result fglrx totally goes crazy, because it change vm_flags
> > even from ->nopage() calback :)

That must be an exciting new State of the Art version of fglrx.

Looking at what I downloaded for inspection a year ago, I can't
see any sign of that. But I do see lots of random stabs at setting
different vm_flags in different mmap cases (VM_IO, VM_SHM, VM_RESERVED,
VM_LOCKED): of which the VM_IO serves some point, VM_SHM is defunct,
VM_RESERVED will be defunct, and VM_LOCKED can confuse us.

But interestingly, where they set VM_LOCKED, they did increment
vm_locked: so there shouldn't be that issue of wrapping negative
on munmap, which had worried me. And now I look at Dmitry's
patch again, I see that he was indeed assuming that the driver
had done that incrementation.

> Well, everyone with half a brain knows that fglrx is not just legally
> problematic but an utter piece of junk. We should add more debug checks
> to stop it from doing such stupid things. And yes, chaning flags from
> ->nopage() does not just deserve a warning but a panic.

Well, they'll get what they deserve. I'm not convinced Dmitry's right
about their nopage; and I'm not going to waste any more time working
out ways to protect ourselves from them. Let's stick with the mspec.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-07-11 20:07    [W:0.079 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site