From patchwork Sat Aug 26 03:57:48 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xueshi Hu X-Patchwork-Id: 13366493 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 8DF13C83F01 for ; Sat, 26 Aug 2023 03:58:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 00DFB2800C0; Fri, 25 Aug 2023 23:58:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EFFEF2800BE; Fri, 25 Aug 2023 23:58:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC7F82800C0; Fri, 25 Aug 2023 23:58:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CA8982800BE for ; Fri, 25 Aug 2023 23:58:27 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7B1E2C080D for ; Sat, 26 Aug 2023 03:58:27 +0000 (UTC) X-FDA: 81164898654.20.3AFC4EC Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by imf12.hostedemail.com (Postfix) with ESMTP id DE62540009 for ; Sat, 26 Aug 2023 03:58:23 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=rT4JalxR; dmarc=none; spf=none (imf12.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.215.182) smtp.mailfrom=xueshi.hu@smartx.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693022304; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=oX6TBXoSKdcVe2hZwMHpUN85Ja2Oqu1Hi+5JRnOR9tk=; b=QicuVt1mGddezrmhcMewlkxgx3Cdk2kpRuUbSY7j6EL+2GaMSe+oKWL5vBdRgcueV5AYIW yIduABeNWzY3dS0D1s7z6/zKXGYiRo2GdOaT8LDkOXcAM0qsD5/DPTiFJ1w6TIEQy1g0nY PXKU5XaEbA5WIpux209LQXWV7eUwfkI= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=smartx-com.20221208.gappssmtp.com header.s=20221208 header.b=rT4JalxR; dmarc=none; spf=none (imf12.hostedemail.com: domain of xueshi.hu@smartx.com has no SPF policy when checking 209.85.215.182) smtp.mailfrom=xueshi.hu@smartx.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693022304; a=rsa-sha256; cv=none; b=5LV73PuYSRsKP53NFYSQs3sxZn5KDFMQoQrp3G8ihrFhEVXKg7irGXnZRcdt4NBDvmqUQb rL3SfY1P5oh8KH+5rPg3METYsKzBaa7Af2PBqOKdePY1NBj57OAmRtq61wvjCO0N52TkGS 3P9WL5NEYHvQeRHG3idgR3NjxMVWHJg= Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-56b0c5a140dso963459a12.0 for ; Fri, 25 Aug 2023 20:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartx-com.20221208.gappssmtp.com; s=20221208; t=1693022301; x=1693627101; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=oX6TBXoSKdcVe2hZwMHpUN85Ja2Oqu1Hi+5JRnOR9tk=; b=rT4JalxRnWwUmm4Bp68YHrwVDaOJKFykjCet0hhLjadFS/Pgec8mvvvv6gnQAeeoR7 LDA/om5jiwY2YeBypqNFhBa8+A0BYOjbieUTAMy1eGAWUjKHYFcaOfMImDXijFJswfbI +b42JToURg+vVlne2pInaPRJCMtZTHzsda/q3qkjJ2ouRGKlgEBnb/8VdRE7Ldd9SIjq KIgdqv8wTvuVtVmQXO83Zd531esPoKfXVTysPyoagw/M5FTe9/+hXVTvxG8zlWQbhHGE Lt/5ofdE12bNV1EOJV2zQeIwe3qjFGN9xt6phAdYfEKiWgPLpU5EClGOdL/VpG2XXA63 u2Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693022301; x=1693627101; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oX6TBXoSKdcVe2hZwMHpUN85Ja2Oqu1Hi+5JRnOR9tk=; b=DqhA5KShhJ5odkc4l35YruqqaTxlbFbW9xcwJLnOU2WDgmnMgaG0HazUz7Oomo35aQ 2tTZylf2RSwC8bBpLzUV6KJEDcPA14CyA+QxWqlo5+XRJPYL852mjJy/4rzxssuYxu9/ jzJL5tJZKyFe1Q02Q3hbEBxLDiCICSIoRo9ZSnzUwL/xnQxA1EsJhzzc8aQrVqPMXetD eTGkkhKU3UF79l1+se4r/aF6zg+6iDn1A+U/7M8gmLLeUACC3+fF7XChDp+fik4Qoe9o 2ii1NqyPhen9aYAWjwh3d0sIhVGxU1rhkGASSUOlFjHX80RXmgvhP7vzakvWjJe9NGWk NGZA== X-Gm-Message-State: AOJu0YzKJxOGnm8yXojQSiOkkb6ramjFV0PCrJFiVWXPtLZEfcKmaoBl 07iOAdveM7tYeWRJJ76jxs4T2A== X-Google-Smtp-Source: AGHT+IG2Yw2nwSGMcIIrvCvJUUY+jEO4R+Hf+fFczQ68Axsf9tzph1fCSAfomGkwKVEvbHpkQypm5g== X-Received: by 2002:a05:6a20:7f8a:b0:140:54ab:7f3f with SMTP id d10-20020a056a207f8a00b0014054ab7f3fmr28689344pzj.50.1693022300779; Fri, 25 Aug 2023 20:58:20 -0700 (PDT) Received: from nixos.tailf4e9e.ts.net ([1.202.18.10]) by smtp.googlemail.com with ESMTPSA id fm25-20020a056a002f9900b0068aca503b9fsm2306367pfb.114.2023.08.25.20.58.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Aug 2023 20:58:20 -0700 (PDT) From: Xueshi Hu To: Mike Kravetz , Muchun Song , Andrew Morton , Oscar Salvador , Naoya Horiguchi Cc: Xueshi Hu , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH] mm/hugeltb: fix nodes huge page allocation when there are surplus pages Date: Sat, 26 Aug 2023 11:57:48 +0800 Message-Id: <20230826035748.891697-1-xueshi.hu@smartx.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 X-Rspamd-Queue-Id: DE62540009 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: nrp4npzggs73wscm7n6sy5z4mta6jgau X-HE-Tag: 1693022303-864219 X-HE-Meta: U2FsdGVkX1+9n8hyA/bizpflCBxi503fibqSiEiXE3T/CecUamd88b6oJxyUdZN2R7TDsR9nvRHS9VjbmIiPZpuTVWXHSRIg5GyV5XhzHlTEHPmW2Ht6eHeUJTYZLEwZ/ve+sbk+m+JuniOUfUGWIrbwah5sRKc5nPI+jc0jNtPnKGb+CDu08iPNfUPOHoixt5pevB0BcXa5oQglwgS8CJEs33wzB4sgfv+wRlgUpimC6TPAZvCCIxl/u7Pr9bnnkMvWo0rLc1Xg9jS374fioWu/LJNky0P35hFxaRoCpw5gvYJuG7CgqhWkhIoSdvyIQL+VENWXK8MqLuG0sc1mVoKOn8CYKI2E7mFuIUZI0Nc3IJoDIKTlCmXeH3hyi6T2W0R4MDdSf1k2Nuf9vvuDnLFmjyuDC5P/YQwCynShjLO6TXL4mnCcxChcl60/AhAcUK9+ufYPkjmC+Wi+TUhNCJnfvJEwcY/l3lHR6hbHGjE50SXKW9x4KZKmCfu3NbC2TWSYHu/7ZzBmrHs4vbHCeQkI3hr0fmyNyrnY5gVpUaoifgSvTI1BmQojQy/7HErbqRmxtlVwlysi/SlZdmshnf0z8Wj4BPqxixjl0plG+anIi3yWhWd0phqXxYRaJBZKfEricsJgjMiPDAJTCn5DnEZE19QaCL1N2n1mazOaj1Vi6XzzgA+oQaT1wsvz+zrZI6ZrYwa54qGqykpke3wH6EwCvzteKIKOsnNRotN3LozRmqJTZ8cuGv521Qz+kkiFPtsg7LDEc6dfPDJJikSAlGNOjr7iMDsvfw9dGftXqdRDSvfaCW6ZC3NJS9+9a1CVRzjifWcAeW71geUy6T3n8nGoSUU7+0Xs0bQonJGE4hj08IM/L4Nwyapdb0IQEXmI/rUqd9xVhTaMdcY34gZRQDr3dXm+uhTGl8pMQZOW25KOvBnxWRyac+tpUrHmQQyRxa3waSUoqi6Yu7wY5Ay PCkzQ6Ei yr+BdlTx532P5EFpyxcBbPmvOGxl+3GFeWGjZ2YMcSADcHPuAebXHFBCbwJ+IKkvRZvTVZcrtUJOsLTPPktFTtFgXIgbmHpWlFcDUCxgDBLT+3vYRHeo2gE1hfzIty1qBz/BLomr0ho3dKM0Ixz/SKOD5fOvxJDDVCkMDXd1FvMxyudA7VXW99r2Zc91Wvznjqfn4B4yCuNYek4ku+JzqXRdj0EoYOJnoUY3s4SuTXmIDVACuNV8bTM7XqIVwkrufkaHJO4j0uTv4OKIbFT9GVnAf5pl9bEEN89N5V6/Qz9U4JwZwUFzY84zkLQhWOGHYt0Pv9Ro8EwF62fvMSCAktYFo7bvfEbD1jBMtcy0lw14hqvOuZg3ya/JaiVgEiwO4uehRR2wvxrYFsRJnf6ShKnSG2x5ywORBOhhzehXPJNE1hLo= 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: In set_nr_huge_pages(), local variable "count" is used to record persistent_huge_pages(), but when it cames to nodes huge page allocation, the semantics changes to nr_huge_pages. When there exists surplus huge pages and using the interface under /sys/devices/system/node/node*/hugepages to change huge page pool size, this difference can result in the allocation of an unexpected number of huge pages. Steps to reproduce the bug: Starting with: Node 0 Node 1 Total HugePages_Total 0.00 0.00 0.00 HugePages_Free 0.00 0.00 0.00 HugePages_Surp 0.00 0.00 0.00 create 100 huge pages in Node 0 and consume it, then set Node 0 's nr_hugepages to 0. yields: Node 0 Node 1 Total HugePages_Total 200.00 0.00 200.00 HugePages_Free 0.00 0.00 0.00 HugePages_Surp 200.00 0.00 200.00 write 100 to Node 1's nr_hugepages echo 100 > /sys/devices/system/node/node1/\ hugepages/hugepages-2048kB/nr_hugepages gets: Node 0 Node 1 Total HugePages_Total 200.00 400.00 600.00 HugePages_Free 0.00 400.00 400.00 HugePages_Surp 200.00 0.00 200.00 Kernel is expected to create only 100 huge pages and it gives 200. Fixes: fd875dca7c71 ("hugetlbfs: fix potential over/underflow setting node specific nr_hugepages") Signed-off-by: Xueshi Hu Reviewed-by: Mike Kravetz --- mm/hugetlb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 6da626bfb52e..54e2e2e12aa9 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3494,7 +3494,9 @@ static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid, if (nid != NUMA_NO_NODE) { unsigned long old_count = count; - count += h->nr_huge_pages - h->nr_huge_pages_node[nid]; + count += persistent_huge_pages(h) - + (h->nr_huge_pages_node[nid] - + h->surplus_huge_pages_node[nid]); /* * User may have specified a large count value which caused the * above calculation to overflow. In this case, they wanted