Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 20 Jul 2021 16:28:10 -0700
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Chen Wandun <chenwandun@huawei.com>
Cc:     <0x7f454c46@gmail.com>, <wangkefeng.wang@huawei.com>,
        <weiyongjun1@huawei.com>, <linux-mm@kvack.org>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/mremap: fix memory account on do_munmap() failure
Message-Id: <20210720162810.e4710eebca48e9dc8ce2fa4d@linux-foundation.org>
In-Reply-To: <20210717101942.120607-1-chenwandun@huawei.com>
References: <20210717101942.120607-1-chenwandun@huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Sat, 17 Jul 2021 18:19:42 +0800 Chen Wandun <chenwandun@huawei.com> 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?