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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E920EB64D9 for ; Mon, 19 Jun 2023 07:22:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E0C7F8D0002; Mon, 19 Jun 2023 03:22:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DBC628D0001; Mon, 19 Jun 2023 03:22:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C84CA8D0002; Mon, 19 Jun 2023 03:22:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B6E6C8D0001 for ; Mon, 19 Jun 2023 03:22:30 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8FE18AFC22 for ; Mon, 19 Jun 2023 07:22:30 +0000 (UTC) X-FDA: 80918654460.28.20A019F Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf10.hostedemail.com (Postfix) with ESMTP id ABF2CC000A for ; Mon, 19 Jun 2023 07:22:25 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687159348; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EdOXHJLq7CdgLwDJ31Y2KnX/NDPwHGE+4jttUsnLtYo=; b=XEgEIgLOC1Jw3E4R+I1ABSYYTCPgJI4JDc9oaipeO7fvwQXjaLh69u6nyxR7stoN7rNjwj UXGkmrLUdk9DsHeL47TuS9T5b1ock/WjUQIs5rOKtTUxg1euhxXzUmFzoX35p/Gqpz9YGw eWECPXCbvPpgJFBZxn71QaHmkd3EF4Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687159348; a=rsa-sha256; cv=none; b=QShYE6lh+NQlfkBh671vy3CSLIpBAd6enBQB4UGasSep7HkJffaVMh3pRWyShwAmFF3RbB Obtt8OZ/rm/t+kacREmAdQAIglW6k+1B+DDgUvOF/QJ7S0WiEfty+ZW7p+ClyEcCWJAwZ8 OyLuyUaZBFmwIIyNZfjbErkeM9JYxGc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from dggpemm500014.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Ql1NL1P6NzMpZ8; Mon, 19 Jun 2023 15:19:14 +0800 (CST) Received: from [10.174.178.120] (10.174.178.120) by dggpemm500014.china.huawei.com (7.185.36.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Mon, 19 Jun 2023 15:22:20 +0800 Message-ID: Date: Mon, 19 Jun 2023 15:22:20 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 CC: , , , , , , , , , , , Subject: Re: [PATCH stable 5.10] mm/memory_hotplug: extend offline_and_remove_memory() to handle more than one memory block Content-Language: en-US To: References: <20230619065121.1720912-1-mawupeng1@huawei.com> <2023061926-monoxide-pastor-fa3b@gregkh> From: mawupeng In-Reply-To: <2023061926-monoxide-pastor-fa3b@gregkh> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.120] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500014.china.huawei.com (7.185.36.153) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: ABF2CC000A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: zxopuqz145m95iyyec3nqztkbbyn1i7x X-HE-Tag: 1687159345-787248 X-HE-Meta: U2FsdGVkX19PmXWp9GrtukG+Tt7BmMUJ9kzgYjaKhgp2FAHPhK/JQJMrDWINb8boAyqbg9U72QuNqFoQ7d5nsKT33bUELruLYZRYLxFv8X3mWr57LOo5l47VVtDXUUwOu5mdiQm2F8psXXTsbwbLpZEA+qth5rJtRlHRubNcntnTByP9mEgI34AcWe/KYUx7aws6XMyMLtpUZHFhbIF35TtCz45HEpfmKAWmqvtZk0r5DeFWGdiUeaFTdFI5DnVTEkH43VJULZdlpTG7Xzm7B5M+4ZY0996MFvL4XZtOY1XSPrJxs7AxxEueKN/xaJ2crpVb1qZ9UajcNHKUAb359TsRmWcOh6lAeM/ZgBom2H9EBxP0ohWDEyenRAqw7j2CRcVGKMTCtXjKiTnUiF4G+RmFobiUdZVM9LB06DkW6hlYfufmOrzjacU1AAGuivP5Jop9J+7ClSLyfzscg5NGnmuZsl1m8HESzQym/tPrdWeEx3CO4xeuVE67lLMECWxznuBnntLRkaq0H3y5xtYzN2k7TwWf5AKxUcC/bLLtCGx5ftUUjRDzCmKVOntZYWRqsIvbQsc/tYv2NTove/wFJc/imme3yZBh/PrpKwMhXR2/cUQ9+780PyEn0loBOgJvnZCEuBEZaXqDAuU+MQ7KFU7Uw1mzex3GazgfSv+nN4sjbngskmDI2VIwKAiq3q1H9CKruEGh5aVQJ5ZSQ7zTHV9AujjXMqAeCOedgvjqwelKtTf6xVBn9pX/UFZ9iR7kUiAlhLN2LfYccFsy1VYo2isDfmATiL2oPXsRcBL25eTPkdCH9dhdZiFK8uE4chyz24k2pUb5rHBURTR+YEQrLzgVVpOAEUJri7vROS+68ZcscoQENVCMrSxltOVb8zycPmj91tmZo7F86FuN9rqCyZd4pjM+kTBTnwsVQp07PW+3n7kTp//6zC+cp4hqmB3CRGqNKogCGqsA1RWPqxL 6JmUAsHh DThzXfpTVPXKkaVjb/GEIBZuTTw9KhEqImvmHsq/1zuz3SVVesQW6y7QgTrHZYP6bNvYH+epWkl/AtnNJR/49unBpjILyaYShiYgGUNHOLnnbCybaeU3XqKI+kAOF+RJxpwtOFHsbg91FUr5SQ6jGnYoNEJ4bm9vGMOQd24OTpKlswj6ols0zYCHe9cqKeBPlKP0CBiNQ8Mfk5k8KfGPbKVDv9Ydh6CJ6zi+0V1Mf5kxi7F+d7gnSw/Yz0MD0RenKVzWBp64IpiOUT0p7JtMGgrbtmFQkjxmUFhsH6yjqZtHa97ot9o1W05xt1CJyUD6Lh8nUmOnBlYvcYMVlJ3CmigDV4xQKc8Me3vzCSusNP4RfidX6URb+7w5AeRM/TiW1clcs6vFbHzQKo7HswfJvi6PHJoV003EaPUNpkOMc8RNvzyHXdXZfr/K1+i4DmaX3TOLOGLQa11JVjHy8aRE1sxtFnQ== 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 2023/6/19 15:16, Greg KH wrote: > On Mon, Jun 19, 2023 at 02:51:21PM +0800, Wupeng Ma wrote: >> From: David Hildenbrand >> >> commit 8dc4bb58a146655eb057247d7c9d19e73928715b upstream. >> >> virtio-mem soon wants to use offline_and_remove_memory() memory that >> exceeds a single Linux memory block (memory_block_size_bytes()). Let's >> remove that restriction. >> >> Let's remember the old state and try to restore that if anything goes >> wrong. While re-onlining can, in general, fail, it's highly unlikely to >> happen (usually only when a notifier fails to allocate memory, and these >> are rather rare). >> >> This will be used by virtio-mem to offline+remove memory ranges that are >> bigger than a single memory block - for example, with a device block >> size of 1 GiB (e.g., gigantic pages in the hypervisor) and a Linux memory >> block size of 128MB. >> >> While we could compress the state into 2 bit, using 8 bit is much >> easier. >> >> This handling is similar, but different to acpi_scan_try_to_offline(): >> >> a) We don't try to offline twice. I am not sure if this CONFIG_MEMCG >> optimization is still relevant - it should only apply to ZONE_NORMAL >> (where we have no guarantees). If relevant, we can always add it. >> >> b) acpi_scan_try_to_offline() simply onlines all memory in case >> something goes wrong. It doesn't restore previous online type. Let's do >> that, so we won't overwrite what e.g., user space configured. >> >> Reviewed-by: Wei Yang >> Cc: "Michael S. Tsirkin" >> Cc: Jason Wang >> Cc: Pankaj Gupta >> Cc: Michal Hocko >> Cc: Oscar Salvador >> Cc: Wei Yang >> Cc: Andrew Morton >> Signed-off-by: David Hildenbrand >> Link: https://lore.kernel.org/r/20201112133815.13332-28-david@redhat.com >> Signed-off-by: Michael S. Tsirkin >> Acked-by: Andrew Morton >> Signed-off-by: Ma Wupeng >> --- >> mm/memory_hotplug.c | 105 +++++++++++++++++++++++++++++++++++++------- >> 1 file changed, 89 insertions(+), 16 deletions(-) >> > > Why is this needed in 5.10.y? Looks like a new feature to me, what > problem does it solve there? > > thanks, > > greg k-h It do introduce a new feature. But at the same time, it fix a memleak introduced in Commit 08b3acd7a68f ("mm/memory_hotplug: Introduce offline_and_remove_memory()" Our test find a memleak in init_memory_block, it is clear that mem is never been released due to wrong refcount. Commit 08b3acd7a68f ("mm/memory_hotplug: Introduce offline_and_remove_memory()") failed to dec refcount after find_memory_block which fail to dec refcount to zero in remove memory causing the leak. Commit 8dc4bb58a146 ("mm/memory_hotplug: extend offline_and_remove_memory() to handle more than one memory block") introduce walk_memory_blocks to replace find_memory_block which dec refcount by calling put_device after find_memory_block_by_id. In the way, the memleak is fixed. Here is the simplified calltrace: kmem_cache_alloc_trace+0x664/0xed0 init_memory_block+0x8c/0x170 create_memory_block_devices+0xa4/0x150 add_memory_resource+0x188/0x530 __add_memory+0x78/0x104 add_memory+0x6c/0xb0