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 DA1C2C43334 for ; Tue, 21 Jun 2022 01:36:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5BDD16B0072; Mon, 20 Jun 2022 21:36:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5462A6B0073; Mon, 20 Jun 2022 21:36:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E7AD6B0074; Mon, 20 Jun 2022 21:36:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2B9276B0072 for ; Mon, 20 Jun 2022 21:36:04 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EC17721030 for ; Tue, 21 Jun 2022 01:36:03 +0000 (UTC) X-FDA: 79600527006.19.FE9FF1F Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf22.hostedemail.com (Postfix) with ESMTP id 4DB98C0012 for ; Tue, 21 Jun 2022 01:36:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655775363; x=1687311363; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=1sAEize2JPA180/ucIEiMx0IRlM6GKGbk0JEfZIi4tM=; b=VZCu8xGPFzEler0SYt8GR0dFcCqn/fi/ekWZOq7PKyiYW9kGy8IiqMMK 36d0TWjCvdSCaBBPza6KRYCZS4KsyjsIiX+BrYifarXmjyJPaG+cmf7yH oXIoxBWmsUz7z3dESO9yQYBvQnvjmLPDqXj2KvtsklX41Bse9Itwy0JqL NRYMgP1MVm6SzIbWgzsF14le1q6orcx7PlyPEQ5vJyUmYftaNRz03LKSR jPC37PCutRfV2e0FzmqU3lGEAwyR3EUXy2ZNZN9f6xTzAR8OQAF4m87pe DqzQLasO1bpn9bjmsBCyEpyaEXSU/RSJvYq/JC5imLMG0bkVutnCmUXY5 A==; X-IronPort-AV: E=McAfee;i="6400,9594,10384"; a="278772314" X-IronPort-AV: E=Sophos;i="5.92,207,1650956400"; d="scan'208";a="278772314" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jun 2022 18:35:55 -0700 X-IronPort-AV: E=Sophos;i="5.92,207,1650956400"; d="scan'208";a="654918761" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.13.94]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jun 2022 18:35:53 -0700 From: "Huang, Ying" To: Miaohe Lin Cc: , , , Subject: Re: [PATCH v2 1/3] mm/swapfile: make security_vm_enough_memory_mm() work as expected References: <20220608144031.829-1-linmiaohe@huawei.com> <20220608144031.829-2-linmiaohe@huawei.com> <87r13jrdst.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Tue, 21 Jun 2022 09:35:50 +0800 In-Reply-To: (Miaohe Lin's message of "Mon, 20 Jun 2022 20:12:27 +0800") Message-ID: <87letqpzm1.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655775363; a=rsa-sha256; cv=none; b=Si0Ul7dI2AIL/GimpGL7o52nfXUnwq+xxMLLhOPnzXJhdBzsFAXgsFSZaO7WqF4m8B2ARs Vou8R/ajposku78DJGuwum9TQCYHnKKNRQU3wajChNxJY9ebWJ8eGZZob1LVfe1WnLdu0W ZpqMp963x/bBhVS1fCRFTPZCWoXIxZM= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VZCu8xGP; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655775363; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DZF19WDFvfP6wtFxPPMcICtpeihycHhABcVkMZi8t08=; b=QNlSQKRYImTjcyWSja0vyP2eNvaAlfIlRhZ47CiWA+wM3azpwGy5q2P+Ef97vsDb4avz9s I0fUZ8VW7Anl6lD5wFc3IpqznEGsHPqmH/uQc4T1wDPOuvQA32f1ZSDiRB80x8u1609D3R f3DEm+PDMhxpFSaMGqLVWrGnFTSkkFk= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4DB98C0012 X-Stat-Signature: zhw8tm5noop3349szsy14irnhpjyub54 X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=VZCu8xGP; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 192.55.52.120) smtp.mailfrom=ying.huang@intel.com X-HE-Tag: 1655775363-354732 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: Miaohe Lin writes: > On 2022/6/20 15:31, Huang, Ying wrote: >> Miaohe Lin writes: >> >>> security_vm_enough_memory_mm() checks whether a process has enough memory >>> to allocate a new virtual mapping. And total_swap_pages is considered as >>> available memory while swapoff tries to make sure there's enough memory >>> that can hold the swapped out memory. But total_swap_pages contains the >>> swap space that is being swapoff. So security_vm_enough_memory_mm() will >>> success even if there's no memory to hold the swapped out memory because >>> total_swap_pages always greater than or equal to p->pages. >> >> Per my understanding, swapoff will not allocate virtual mapping by >> itself. But after swapoff, the overcommit limit could be exceeded. >> security_vm_enough_memory_mm() is used to check that. For example, in a >> system with 4GB memory and 8GB swap, and 10GB is in use, >> >> CommitLimit: 4+8 = 12GB >> Committed_AS: 10GB >> >> security_vm_enough_memory_mm() in swapoff() will fail because >> 10+8 = 18 > 12. This is expected because after swapoff, the overcommit >> limit will be exceeded. >> >> If 3GB is in use, >> >> CommitLimit: 4+8 = 12GB >> Committed_AS: 3GB >> >> security_vm_enough_memory_mm() in swapoff() will succeed because >> 3+8 = 11 < 12. This is expected because after swapoff, the overcommit >> limit will not be exceeded. > > In OVERCOMMIT_NEVER scene, I think you're right. > >> >> So, what's the real problem of the original implementation? Can you >> show it with an example as above? > > In OVERCOMMIT_GUESS scene, in a system with 4GB memory and 8GB swap, and 10GB is in use, > pages below is 8GB, totalram_pages() + total_swap_pages is 12GB, so swapoff() will succeed > instead of expected failure because 8 < 12. The overcommit limit is always *ignored* in the > below case. > > if (sysctl_overcommit_memory == OVERCOMMIT_GUESS) { > if (pages > totalram_pages() + total_swap_pages) > goto error; > return 0; > } > > Or am I miss something? Per my understanding, with OVERCOMMIT_GUESS, the number of in-use pages isn't checked at all. The only restriction is that the size of the virtual mapping created should be less than total RAM + total swap pages. Because swapoff() will not create virtual mapping, so it's expected that security_vm_enough_memory_mm() in swapoff() always succeeds. Best Regards, Huang, Ying > > Thanks! > >> >>> In order to fix it, p->pages should be retracted from total_swap_pages >>> first and then check whether there's enough memory for inuse swap pages. >>> >>> Signed-off-by: Miaohe Lin >> >> [snip] >> >> . >>