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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
