On Sat, 17 Jul 2021 18:19:42 +0800 Chen Wandun <chenwandun@xxxxxxxxxx> wrote: > mremap will account the delta between new_len and old_len in > vma_to_resize, and then call move_vma when expanding an existing > memory mapping. In function move_vma, there are two scenarios when > calling do_munmap: > 1. move_page_tables from old_addr to new_addr success > 2. move_page_tables from old_addr to new_addr fail > > In first scenario, it should account old_len if do_munmap fail, > because the delta has already been accounted. > > In second scenario, new_addr/new_len will assign to old_addr/old_len > if move_page_table fail, so do_munmap is try to unmap new_addr actually, > if do_munmap fail, it should account the new_len, because error code > will be return from move_vma, and delta will be unaccounted. > What'more, because of new_len == old_len, so account old_len also is > OK. > > In summary, account old_len will be correct if do_munmap fail. Sorry, but I'm having trouble following that description. Dmitry, could you please review this change and then assist in clarifying the changelog text? Also, could it be argued that we're doing this in the wrong place? Should it be the responsibility of do_munmap() to fix up the accounting if it is going to return an error? Rather than expecting the do_munmap() caller to fix up do_munmap()'s mess? Thirdly, is the comment in there true? Does this accounting error only occur due to ENOMEM? If that is the case then I am inclined not to backport this fix into -stable kernels, as the error is so unlikely to be triggered. Thoughts on this?
