From: Hugh Dickins <hugh@veritas.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jes Sorensen <jes@sgi.com>, Dmitry Monakhov <dmonakhov@sw.ru>,
linux-kernel@vger.kernel.org
Subject: Re: [patch] mm: recheck lock rlim after f_op->mmap() method
Date: Wed, 11 Jul 2007 19:03:36 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0707111826530.22786@blonde.wat.veritas.com> (raw)
In-Reply-To: <20070711101437.GA21735@infradead.org>
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
next prev parent reply other threads:[~2007-07-11 18:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-09 18:49 Dmitry Monakhov
2007-07-10 17:27 ` Hugh Dickins
2007-07-10 17:53 ` Dmitry Monakhov
2007-07-10 19:48 ` Hugh Dickins
2007-07-11 8:39 ` Jes Sorensen
2007-07-11 18:24 ` Hugh Dickins
2007-07-11 9:32 ` Christoph Hellwig
2007-07-11 10:12 ` Dmitry Monakhov
2007-07-11 10:14 ` Christoph Hellwig
2007-07-11 18:03 ` Hugh Dickins [this message]
2007-07-13 9:53 ` Christoph Hellwig
2007-07-13 8:13 ` Andrew Morton
2007-07-13 13:02 ` Hugh Dickins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0707111826530.22786@blonde.wat.veritas.com \
--to=hugh@veritas.com \
--cc=dmonakhov@sw.ru \
--cc=hch@infradead.org \
--cc=jes@sgi.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®