On Wed, 9 Feb 2005, Chris Wright wrote: > * Hugh Dickins (hugh@private) 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
This archive was generated by hypermail 2.1.3 : Wed Feb 09 2005 - 13:47:56 PST