linux-kernel - Re: [PATCH] Fix OOPS in mmap_region() when merging adjacent VM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 30 Jan 2009 14:27:23 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Lee Schermerhorn <Lee.Schermerhorn@...com>
cc:	Hugh Dickins <hugh@...itas.com>, Greg KH <gregkh@...e.de>,
	Maksim Yevmenkin <maksim.yevmenkin@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Nick Piggin <npiggin@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	will@...wder-design.com, Rik van Riel <riel@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Mikos Szeredi <miklos@...redi.hu>
Subject: Re: [PATCH] Fix OOPS in mmap_region() when merging adjacent VM_LOCKED
 file segments

On Fri, 30 Jan 2009, Lee Schermerhorn wrote:
> 
> I just verified that adding VM_ACCOUNT to VM_MERGEABLE does allow the
> merge to happen with the test program.  And the system didn't come
> crashing down around me.  But, I wouldn't trust that simple test as the
> last word.  A short run of a stress load I use held up/still running,
> but I can't tell whether it's merging as expected there.   

Just ignoring VM_ACCOUNT for merging is not the right thing to do. It 
probably works in practice for just about everything, but at least in 
theory it does mean that mmap() can stop honoring MAP_NORESERVE.

Admittedly the circumstances where that happens are unlikely, and nobody 
probably even really uses MAP_NORESERVE in the first place, so I doubt you 
can ever see it as a real issue, but it's still technically wrong to merge 
vma's that can differ in VM_ACCOUNT.

Now, the particular test you have, VM_ACCOUNT differs only during that 
temporary window, and the vma's really do end up with the same VM_ACCOUNT 
state in the end, so merging them is correct, but if you were to privately 
map the same file (or private anonymous map) with the same permissions 
next to each other so that they -could- merge, but use MAP_NORESERVE on 
one and not on the other, then they shouldn't merge.

So VM_ACCOUNT does matter - just barely - for merging, and we just happen 
to currently hit it too much due to a very odd internal reason.

		Linus
--
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/