[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0901292200220.17808@blonde.anvils>
Date: Thu, 29 Jan 2009 22:32:54 +0000 (GMT)
From: Hugh Dickins <hugh@...itas.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: Lee Schermerhorn <Lee.Schermerhorn@...com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Maksim Yevmenkin <maksim.yevmenkin@...il.com>,
Nick Piggin <npiggin@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...e.de>, will@...wder-design.com,
Rik van Riel <riel@...hat.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Subject: Re: [PATCH] Fix OOPS in mmap_region() when merging adjacent VM_LOCKED
file segments
On Thu, 29 Jan 2009, Linus Torvalds wrote:
> On Thu, 29 Jan 2009, Linus Torvalds wrote:
> >
> > THIS PATCH IS TOTALLY UNTESTED!
Sorry, I was away yesterday, and not yet caught up with things today.
I certainly agree that it would be much nicer not to allocated a vma
in one place, then later throw it away on finding it can be merged:
your patch looks a plausible improvement.
The problem has always been that file->f_op->mmap(file, vma) on a
special file can do various strange things, changing surprising
fields of the struct vma passed to it, changing its mergeability.
Now it may well be that every driver which does something strange
there already sets one of the VM_SPECIAL flags which prevent merging,
or can easily be fixed to do so, or otherwise clearly cannot pose a
problem.
But I need to mull it over and do some checking tomorrow:
anything I say tonight, I'd probably change my mind about.
Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists