From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20237C07E9B for ; Tue, 20 Jul 2021 23:28:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B7C11600D4 for ; Tue, 20 Jul 2021 23:28:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B7C11600D4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6BF9C6B0011; Tue, 20 Jul 2021 19:28:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66FEF6B0036; Tue, 20 Jul 2021 19:28:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 537876B006C; Tue, 20 Jul 2021 19:28:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0128.hostedemail.com [216.40.44.128]) by kanga.kvack.org (Postfix) with ESMTP id 2DF446B0011 for ; Tue, 20 Jul 2021 19:28:15 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A17A220BFE for ; Tue, 20 Jul 2021 23:28:13 +0000 (UTC) X-FDA: 78384556866.28.44AF2B6 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf03.hostedemail.com (Postfix) with ESMTP id 47B4E30013C9 for ; Tue, 20 Jul 2021 23:28:13 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 125C661165; Tue, 20 Jul 2021 23:28:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1626823692; bh=pZ4VoRnokIR9onzVreo9fLmob6Y3sBGkp5Ds0EVJjhM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=EdBQodRejK5wyrYq6wz0piYROUp3iT+9dF45XPFy0WI1yovjAjDI+hqIkKGatheg4 gcKjOQMvS9xBmleIESd4gZKxIvF/lYjjsQMSMEsP6tHz0dXWhmirIvQK1S5meOSqCp eRDoig4pKc/LzI07o+djctGoZj3GTL7Aa5SPdG/o= Date: Tue, 20 Jul 2021 16:28:10 -0700 From: Andrew Morton To: Chen Wandun Cc: <0x7f454c46@gmail.com>, , , , 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> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=EdBQodRe; spf=pass (imf03.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam02 X-Stat-Signature: 4ojhbynb6u9ex65bj7ibhbxg9f9nre58 X-Rspamd-Queue-Id: 47B4E30013C9 X-HE-Tag: 1626823693-864483 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, 17 Jul 2021 18:19:42 +0800 Chen Wandun 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?