lkml.org 
[lkml]   [2005]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] kernel/fork.c: VM accounting bugfix (2.6.11-rc3-bk5)
On Wed, 9 Feb 2005, Chris Wright wrote:

> * Hugh Dickins (hugh@veritas.com) wrote:
> > dup_mmap's charge starts out at 0 and gets added to each time around
> > the loop through vmas; if security_vm_enough_memory fails at any point
> > in that loop, we need to vm_unacct_memory the charge already accumulated.
>
> If that's the requirement, then it's broken as is, because there is
> nothing accumulating. len is re-determined each pass, and charge is
> reset each pass.

You're right, it's me who's wrong, sorry. I was remembering how it
was before 2.6.7, when Oleg pointed out that it was doubly unaccounting
(and it's probably me who was guilty of that double unaccounting too).

> But I think that it's ok, as we only care about the
> last pass. If dup_mmap() fails part way through, the cleanup path should
> call unaccount for the (potentially) accounted by not fully setup vma then
> call exit_mmap() and clear all the vmas that got accounted for already.

Yes, that was Oleg's point when he fixed it.

> Either way, Mark's patch is not needed, and I don't think anything needs
> patching in this area. Hugh, do you agree?

Yes I agree - thanks for clearing that up, Chris.

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: 2005-03-22 14:10    [W:0.030 / U:1.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site