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 27C39C433EF for ; Mon, 20 Jun 2022 07:32:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 97DAE8E0001; Mon, 20 Jun 2022 03:32:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 905B36B0073; Mon, 20 Jun 2022 03:32:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A54D8E0001; Mon, 20 Jun 2022 03:32:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 674E96B0071 for ; Mon, 20 Jun 2022 03:32:23 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2F10133DC3 for ; Mon, 20 Jun 2022 07:32:23 +0000 (UTC) X-FDA: 79597796166.20.7888455 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf19.hostedemail.com (Postfix) with ESMTP id 375FA1A00A6 for ; Mon, 20 Jun 2022 07:32:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1655710340; x=1687246340; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=+G28GLDrdNJ98I4YnokMT1hGC4CArBlW7m+z/O+dMU4=; b=n2SlGLjmowEJEzGNBqQXAgslKGgZkwCORSIrCBmxTS/YMMCQFwDAGaPP kuSqeuyAgKPkRDaq6NOg4bSdUXKN5P1XY5C6kJqsr3ya2wCQbdfviH8uM y2xohVTZbKgKf3sGW8vQ9P4nolrVPNQwrgxR96OgabwFGx54dfxYCKhks i3/mln7zvOA72coYXPEhvEP9P8WBm2hDJIwmDs0+cm9+HHHRXAWi2Otx4 aamNo5mfqcTmG7+bre9hZHSSywVFva/B/b1Nu2Lr8OCDBXC9cenJZh15g v4V747YO43foI0Aqc1js0s0XKVvkhbi6kQkepoXso3OSrb578awu3TIW5 Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10380"; a="277376729" X-IronPort-AV: E=Sophos;i="5.92,306,1650956400"; d="scan'208";a="277376729" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jun 2022 00:32:18 -0700 X-IronPort-AV: E=Sophos;i="5.92,306,1650956400"; d="scan'208";a="832989989" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.13.94]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jun 2022 00:32:17 -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> Date: Mon, 20 Jun 2022 15:31:46 +0800 In-Reply-To: <20220608144031.829-2-linmiaohe@huawei.com> (Miaohe Lin's message of "Wed, 8 Jun 2022 22:40:29 +0800") Message-ID: <87r13jrdst.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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655710342; 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=YGz9QXIa/300Oa9qr+q2GnbFEjQdMjKWYpd1tY+Xuc0=; b=CB2zSBWRZalPM3j6Yncix3luGco9eRJyDW/JQKcblBYYOCobofXWW6sxmF3WZHvIk3coxb RkltQdbzlodMgtePZUWQA5BwT+Kw0gmpzmBDVyROxsRmSUfMQ4CBhkis2fCVoY2XpJ+NaD VqnPYc8TLhQCIdYN+jftUj9P5WBhpao= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=n2SlGLjm; spf=none (imf19.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655710342; a=rsa-sha256; cv=none; b=Z12iaMVrWAqbwxk2jzHW7cU2gQlDycuqE0/Cnrynz/hTy1her+5U1I9+/KYJLISN0Dvt3c 6rgxh7DyQ2jXz7UzWhHQjFWva6YuioqG+Rzqm6lVMoaBZUMEjMIMLTZ57UqyWByjgyx4jR uD4FpyVP4DEZf6jRRyUpnE+MwysvJiU= X-Stat-Signature: i3s7qq4xheadaed8c3f1w163cjxky7s9 X-Rspamd-Queue-Id: 375FA1A00A6 X-Rspamd-Server: rspam11 X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=n2SlGLjm; spf=none (imf19.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-HE-Tag: 1655710340-58801 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: > 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. So, what's the real problem of the original implementation? Can you show it with an example as above? Best Regards, Huang, Ying > 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]