From nobody Sat Feb 7 23:56:05 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 35C741F755B for ; Tue, 7 Jan 2025 20:40:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282415; cv=none; b=PgTSPUrYouzib1B0P1m9QfkviqrU6xUdYGi/nGQwOjINNNQLfIsBokgRahC25133VDoRjFmOO0Yf2AOLobtaQmxjHaBVEy8RRIUsoR7zXdaemk1mHC8aS/7yyGkIgSJmw1xi9UJD2hykLH6M9nvzPaFeUb3RMDwqdXsYy+/z6mU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282415; c=relaxed/simple; bh=OrlV9telHLmipLDh600rO1pzIX30pRvc2kgciEpZ1Vg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lIyOBQlW+Y/rgJJqzu+/Og1K5fG5qgMMidk2L5LmrcFSO+dyKFtu3Iy0RjGestIzzzolt09flZIRFJ7tDwnJWVTXLSvbtsfC7zDC/R7XEkN4UBFQYLh532LTNunpT09yK6nri5W/Z/x4BQLV7lWHkfwekUv9cw+OxDENg8D5dAE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=IGhUxtfL; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="IGhUxtfL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736282412; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7lk3UnwL4Id+x/YZ2BCdCNZ6wF+YE+g3ghMfVfHdxsk=; b=IGhUxtfL8SVvt+NermU8ATSGYJhFVcCfUkvwTZq/ao0U2j45nZN2GnSlqtUObV+ttukBQ5 zwsLZGRjbELoaC2GKgHi7R87Wj9wz7WFSn/Tj19qNQSsn+z5NrRUbTWvvET7o7RkiiockP sqTWrrIjOasv6xWzvAnYMCga6uuzfTo= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-417-uRd5ldLRMtyM06o2jCp6yQ-1; Tue, 07 Jan 2025 15:40:09 -0500 X-MC-Unique: uRd5ldLRMtyM06o2jCp6yQ-1 X-Mimecast-MFC-AGG-ID: uRd5ldLRMtyM06o2jCp6yQ Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-6d8f8f69fb5so2619196d6.1 for ; Tue, 07 Jan 2025 12:40:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736282408; x=1736887208; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7lk3UnwL4Id+x/YZ2BCdCNZ6wF+YE+g3ghMfVfHdxsk=; b=EfIcqbgSIDFImkXBihcmAzKwZotlV9I4UbK+tfofGQPNkArQ5MFdaxMoPRblzYGtte w2ItVwmCL3iOBonmUyDood1rrqtMl6BOGOT4fKe8qsdI3ZX/5CHIoXNQOXnPISAQTPDF rxJ0CeUwJ/CPygVIIEVbpiUqgNCdOCHJUGKpdjiNUtDl3FMV+Yo+vJZM+56B+qYjXura f2s7VPz0H1kLWavQ35rtwcrVSlCT5DSL7o4MQnd7pmB9N0vRCId6Cs1dUSUPVsfhuRZN IqLZlHMjc6fZT1+C9QJwar4O7uqfbRl1BBTQM7FNNv2tV4W5gPmH4TUzu+z+8IhWsazn 0gxA== X-Forwarded-Encrypted: i=1; AJvYcCU9PWAYlP4ZRg5YFXZ2jc+fJtXJz9wnMMLp1Ijj8ifGyxeJ78TAiMcmvMFJ21+2WbWQQPkmQK94sKJmshQ=@vger.kernel.org X-Gm-Message-State: AOJu0YzQSOCcUzY1RilgcLjMBAkAEQUvbzzZw5whEE/ET/D2yfA7ennT Vy1KPCN+gs33zLL+DexcvaObfFPHG6BptbZE87Bsn0W3Xh3mvhQfHrvQU9KEjq89gavp1bdO08U h2DcUjv1oorZPSTvmbjF+BCCLCqckBiIzLiQboUahbtmtzr6upHTGGJoWid+BSw== X-Gm-Gg: ASbGncvHXw2XaSss0SPlLSH8Eshc2Y9hIT435QvUXK7IiZ9+3+CzsRGAHDwjnxGmaNi FuIw/KJqFJHQdQ5OTx5kSCQUwJibufmfyK4fdw4AB2pkwi9yw4BobqD5mOBvfoUftuy9+HtMYsu UOTljBpprYUx08vvsdFhLl4fe/uyO9FEuOg2yYp2r3AyVrGLC831tzsP8HM4dK5Xjxqv25DcL/O HNMfJUHchFBpNNZejOE/0p5MRh/gnTbT2hhViMiSOHo3OXwG+9mVA+O1pW9Wn2Uwl3rU5Co+fC/ rcCR2tTyKL3nIisMRYeGiPueQRb9CJAK X-Received: by 2002:ad4:5dc5:0:b0:6d8:b660:f6aa with SMTP id 6a1803df08f44-6df9adfb518mr7494686d6.14.1736282407068; Tue, 07 Jan 2025 12:40:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IE4opU0e+dfjClXuwDmR9cg3uGQm3YY2brmnjieEI+XeJr35YfbdedExB7KgsOyuQE8PaeuGA== X-Received: by 2002:ad4:5dc5:0:b0:6d8:b660:f6aa with SMTP id 6a1803df08f44-6df9adfb518mr7494476d6.14.1736282406765; Tue, 07 Jan 2025 12:40:06 -0800 (PST) Received: from x1n.redhat.com (pool-99-254-114-190.cpe.net.cable.rogers.com. [99.254.114.190]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd181373f6sm184478306d6.62.2025.01.07.12.40.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jan 2025 12:40:06 -0800 (PST) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Breno Leitao , Rik van Riel , Muchun Song , Naoya Horiguchi , Roman Gushchin , Ackerley Tng , Andrew Morton , peterx@redhat.com, Oscar Salvador , linux-stable Subject: [PATCH v2 1/7] mm/hugetlb: Fix avoid_reserve to allow taking folio from subpool Date: Tue, 7 Jan 2025 15:39:56 -0500 Message-ID: <20250107204002.2683356-2-peterx@redhat.com> X-Mailer: git-send-email 2.47.0 In-Reply-To: <20250107204002.2683356-1-peterx@redhat.com> References: <20250107204002.2683356-1-peterx@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Since commit 04f2cbe35699 ("hugetlb: guarantee that COW faults for a process that called mmap(MAP_PRIVATE) on hugetlbfs will succeed"), avoid_reserve was introduced for a special case of CoW on hugetlb private mappings, and only if the owner VMA is trying to allocate yet another hugetlb folio that is not reserved within the private vma reserved map. Later on, in commit d85f69b0b533 ("mm/hugetlb: alloc_huge_page handle areas hole punched by fallocate"), alloc_huge_page() enforced to not consume any global reservation as long as avoid_reserve=3Dtrue. This operation doesn't look correct, because even if it will enforce the allocation to not use global reservation at all, it will still try to take one reservation from the spool (if the subpool existed). Then since the spool reserved pages take from global reservation, it'll also take one reservation globally. Logically it can cause global reservation to go wrong. I wrote a reproducer below, trigger this special path, and every run of such program will cause global reservation count to increment by one, until it hits the number of free pages: #define _GNU_SOURCE /* See feature_test_macros(7) */ #include #include #include #include #include #include #define MSIZE (2UL << 20) int main(int argc, char *argv[]) { const char *path; int *buf; int fd, ret; pid_t child; if (argc < 2) { printf("usage: %s \n", argv[0]); return -1; } path =3D argv[1]; fd =3D open(path, O_RDWR | O_CREAT, 0666); if (fd < 0) { perror("open failed"); return -1; } ret =3D fallocate(fd, 0, 0, MSIZE); if (ret !=3D 0) { perror("fallocate"); return -1; } buf =3D mmap(NULL, MSIZE, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0); if (buf =3D=3D MAP_FAILED) { perror("mmap() failed"); return -1; } /* Allocate a page */ *buf =3D 1; child =3D fork(); if (child =3D=3D 0) { /* child doesn't need to do anything */ exit(0); } /* Trigger CoW from owner */ *buf =3D 2; munmap(buf, MSIZE); close(fd); unlink(path); return 0; } It can only reproduce with a sub-mount when there're reserved pages on the spool, like: # sysctl vm.nr_hugepages=3D128 # mkdir ./hugetlb-pool # mount -t hugetlbfs -o min_size=3D8M,pagesize=3D2M none ./hugetlb-pool Then run the reproducer on the mountpoint: # ./reproducer ./hugetlb-pool/test Fix it by taking the reservation from spool if available. In general, avoid_reserve is IMHO more about "avoid vma resv map", not spool's. I copied stable, however I have no intention for backporting if it's not a clean cherry-pick, because private hugetlb mapping, and then fork() on top is too rare to hit. Cc: linux-stable Fixes: d85f69b0b533 ("mm/hugetlb: alloc_huge_page handle areas hole punched= by fallocate") Reviewed-by: Ackerley Tng Tested-by: Ackerley Tng Signed-off-by: Peter Xu Reviewed-by: Oscar Salvador --- mm/hugetlb.c | 22 +++------------------- 1 file changed, 3 insertions(+), 19 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 354eec6f7e84..2bf971f77553 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1394,8 +1394,7 @@ static unsigned long available_huge_pages(struct hsta= te *h) =20 static struct folio *dequeue_hugetlb_folio_vma(struct hstate *h, struct vm_area_struct *vma, - unsigned long address, int avoid_reserve, - long chg) + unsigned long address, long chg) { struct folio *folio =3D NULL; struct mempolicy *mpol; @@ -1411,10 +1410,6 @@ static struct folio *dequeue_hugetlb_folio_vma(struc= t hstate *h, if (!vma_has_reserves(vma, chg) && !available_huge_pages(h)) goto err; =20 - /* If reserves cannot be used, ensure enough pages are in the pool */ - if (avoid_reserve && !available_huge_pages(h)) - goto err; - gfp_mask =3D htlb_alloc_mask(h); nid =3D huge_node(vma, address, gfp_mask, &mpol, &nodemask); =20 @@ -1430,7 +1425,7 @@ static struct folio *dequeue_hugetlb_folio_vma(struct= hstate *h, folio =3D dequeue_hugetlb_folio_nodemask(h, gfp_mask, nid, nodemask); =20 - if (folio && !avoid_reserve && vma_has_reserves(vma, chg)) { + if (folio && vma_has_reserves(vma, chg)) { folio_set_hugetlb_restore_reserve(folio); h->resv_huge_pages--; } @@ -3047,17 +3042,6 @@ struct folio *alloc_hugetlb_folio(struct vm_area_str= uct *vma, gbl_chg =3D hugepage_subpool_get_pages(spool, 1); if (gbl_chg < 0) goto out_end_reservation; - - /* - * Even though there was no reservation in the region/reserve - * map, there could be reservations associated with the - * subpool that can be used. This would be indicated if the - * return value of hugepage_subpool_get_pages() is zero. - * However, if avoid_reserve is specified we still avoid even - * the subpool reservations. - */ - if (avoid_reserve) - gbl_chg =3D 1; } =20 /* If this allocation is not consuming a reservation, charge it now. @@ -3080,7 +3064,7 @@ struct folio *alloc_hugetlb_folio(struct vm_area_stru= ct *vma, * from the global free pool (global change). gbl_chg =3D=3D 0 indicates * a reservation exists for the allocation. */ - folio =3D dequeue_hugetlb_folio_vma(h, vma, addr, avoid_reserve, gbl_chg); + folio =3D dequeue_hugetlb_folio_vma(h, vma, addr, gbl_chg); if (!folio) { spin_unlock_irq(&hugetlb_lock); folio =3D alloc_buddy_hugetlb_folio_with_mpol(h, vma, addr); --=20 2.47.0 From nobody Sat Feb 7 23:56:05 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CFB361F7084 for ; Tue, 7 Jan 2025 20:40:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282413; cv=none; b=OtS20CT0mj8iHa8KY/rVGvwB++cXmevweGcbCim0mJ2IdTfFe4xMDPM6oVgx1SW77kMN7RgJfCuq0axAhEbxedoRsASzYNffFVZ4+MtklSWKkgA6S+Dl0Wi3/z0daxaO9j+ESYyAeNm7rDGT+/Q9v8fNi2wMA1Zoe0SSBtpxgiY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282413; c=relaxed/simple; bh=bI8G4azuTQeCZEhyU7iiUi2Rp8UTjMbgoMqwM954kJ4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fSOY1JmvfV7oRM+qCJ/vqp0jrj6I22vZkEj/WO73MD/uQcyjoa7ajTDBfu/1qVRP7dfB+yOEh1RAdXSX2GX6Zjxp7XZ86lDWYwHnb8Gzapu/gGaAJbIxRz2epKNAQ8JMbRLL7OwmXot7ZmENgNOkpO1Z/ynE1vXxiMwV9WNCeBY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=O6dPWhbb; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="O6dPWhbb" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736282410; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TCpDisLLwvCIGNbT+PhKKopNoYb0ShL8WntNQkEFj2A=; b=O6dPWhbbHoypQeIy80eWyxVregsimtBDt4aVaZ1fJ02+8ewCbdwc8WpKUS7N1L8ckafu1Q 0YQ8ltqHz2VIjbcaEvR1Ociklf6DjUuEjgnRQT0vmBlw6jSF5775k/+2Z9QTUsjwPpqUQa LJST84HIFDm+w/faFKtHUYhJxyndH0k= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-518-Z-t-OrjgNj2BzkCuhS98dw-1; Tue, 07 Jan 2025 15:40:09 -0500 X-MC-Unique: Z-t-OrjgNj2BzkCuhS98dw-1 X-Mimecast-MFC-AGG-ID: Z-t-OrjgNj2BzkCuhS98dw Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-6d8f78fdad0so241922896d6.2 for ; Tue, 07 Jan 2025 12:40:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736282409; x=1736887209; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TCpDisLLwvCIGNbT+PhKKopNoYb0ShL8WntNQkEFj2A=; b=FNomItEGg1iSVyh9M0mxeZGMsbeJGmVttyWKNBEuqv3T0bLgPE9kEOXF/JCav3+3k4 0J0Dc1LcCjB0jfDZITtGdso36SVKW7LtkSrV3sOzxukBiop7XMF6at45GrqCaaStpPsV PJ6tGSKJrRQKaEGvh8kAjuxjCGZRH042m8jcL2GRfjzR5b48kpqCa4kfN+1ZKwCpk1yA mMCNTtPNoUSkO08Aod0dTvxI05gKGxSPfr4iuNr9LkiR5dvVSYE9kl+jqGHiARdx36eH u4RObvIZ8Mlpvz2Te5iZ0qZmR1J9AcH++JNtZvaEv26wJS5FaAm8ODC84fTh+MaiOPp2 k7EA== X-Forwarded-Encrypted: i=1; AJvYcCWTqw0q1tHh8DvQSZkcuISVvx2Nxi67M0pesdb8JgVEUoLQaBkZNlbc2YZ2auzKo8dogI3UOaArJ/0mDrI=@vger.kernel.org X-Gm-Message-State: AOJu0YxculT6XaQ9F4n49wTkcsDrbjYVdp8tDVfZLJqxqjQtcYh50+kb 1FESgTQpvhIp0J2y6OWN8O8sjxnVOwGikL7byTyGXJ84QRClmOEqN1vOPthBDRIXDtois8z+M8Q +DJDroC5FUkYXMXa/9G/IthyMbstD5c9qCjQ2iQxyVdGFmKkOUxDZjXR2cwIN/A== X-Gm-Gg: ASbGnctpfn2sg7Swwi60iMk9IUCS+lesHVjo+by8vSrDm6ipOmaVWJwpXODixLNPfXd rOoNO4Zuly2ViFZhajCy17TwCAg+DT1yJwWQOUenZ0ICpjFotcfdxC335ZQViRnBE1s3pvQyxmj 2H7vv+whuwM9TAGtpUiU6U4jlVyM2Yn7Sjt/Ld6OoH/NUlpJSGxNovfH1qDCKZOZkVFmd2cfT4W L8abYxQkJuy16VJc4tnBTm+NT0wJ8sNOMGHlsbh6x9MYnOjr9pZCoCgN3uY2U0y0wD5JiBqc15D olPGyhWdZTl+dujy+1vVffLG/yCj0zs0 X-Received: by 2002:a05:6214:62c:b0:6d8:e641:da29 with SMTP id 6a1803df08f44-6df9b1cb73bmr8045776d6.6.1736282409136; Tue, 07 Jan 2025 12:40:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IFsmPVbepwscx9u5TPGeWDqEKCt+YxjZ5PHErDxy3KLOftZYeSvZ9Ie5a+UMBDrcG7IfTLdxQ== X-Received: by 2002:a05:6214:62c:b0:6d8:e641:da29 with SMTP id 6a1803df08f44-6df9b1cb73bmr8045476d6.6.1736282408878; Tue, 07 Jan 2025 12:40:08 -0800 (PST) Received: from x1n.redhat.com (pool-99-254-114-190.cpe.net.cable.rogers.com. [99.254.114.190]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd181373f6sm184478306d6.62.2025.01.07.12.40.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jan 2025 12:40:08 -0800 (PST) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Breno Leitao , Rik van Riel , Muchun Song , Naoya Horiguchi , Roman Gushchin , Ackerley Tng , Andrew Morton , peterx@redhat.com, Oscar Salvador Subject: [PATCH v2 2/7] mm/hugetlb: Stop using avoid_reserve flag in fork() Date: Tue, 7 Jan 2025 15:39:57 -0500 Message-ID: <20250107204002.2683356-3-peterx@redhat.com> X-Mailer: git-send-email 2.47.0 In-Reply-To: <20250107204002.2683356-1-peterx@redhat.com> References: <20250107204002.2683356-1-peterx@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When fork() and stumble on top of a dma-pinned hugetlb private page, CoW must happen during fork() to guarantee dma coherency. In this specific path, hugetlb pages need to be allocated for the child process. Stop using avoid_reserve=3D1 flag here: it's not required to be used here, as dest_vma (which is destined to be a MAP_PRIVATE hugetlb vma) will have no private vma resv map, and that will make sure it won't be able to use a vma reservation later. No functional change intended with this change. Said that, it's still wanted to do this, so as to reduce the usage of avoid_reserve to the only one user, which is also why this flag was introduced initially in commit 04f2cbe35699 ("hugetlb: guarantee that COW faults for a process that called mmap(MAP_PRIVATE) on hugetlbfs will succeed"). I don't see whoever else should set it at all. Further patch will clean up resv accounting based on this. Signed-off-by: Peter Xu Reviewed-by: Oscar Salvador --- mm/hugetlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 2bf971f77553..7be8c35d2a83 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5369,7 +5369,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, st= ruct mm_struct *src, spin_unlock(src_ptl); spin_unlock(dst_ptl); /* Do not use reserve as it's private owned */ - new_folio =3D alloc_hugetlb_folio(dst_vma, addr, 1); + new_folio =3D alloc_hugetlb_folio(dst_vma, addr, 0); if (IS_ERR(new_folio)) { folio_put(pte_folio); ret =3D PTR_ERR(new_folio); --=20 2.47.0 From nobody Sat Feb 7 23:56:05 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5AD5F1F7586 for ; Tue, 7 Jan 2025 20:40:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282416; cv=none; b=Al6yNB0OpDcFKfgRFpKaabnWcMoYCrQ6ogrzydIoEwDJaj3YZHtsM3TT9CL5rVgPHIqgnJKTX7kSqtceKeGs9eQ6ZuOnn6aNfk4Jz+psdGYnJDPItBJIteusWuIxEdOvWWsttX0H0vRbvDHoK1pqV53S44O3GnxxeBhaLfM9CP8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282416; c=relaxed/simple; bh=rWneKYGt7D2DFvoz8LH5TQEfbGYz4EU5IesPIUTseFs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Akc1T9hSptbxM5c08Ne90EXun3zFjoWp8jelfy90VKPzcJFKAWQGT6vcwys9F8eNzajn4pXXF15C5mtNWczenfALbEiHK69d2kV6XFB1V3mbaKaMbP9vIKRINYDCUAxgrWro0gdQlYB6a7MfVIunf4Bv7vWDMA74wQf9JxeoHwY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=JkPKe9qw; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="JkPKe9qw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736282413; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/Z9zMvty6z22PLVpM0GzhFMnUyCY+IlYCy3OrPbUsSM=; b=JkPKe9qwGcy1QEAo9qOdU/Z9Vf8vwF4jmGk7KuosSLx8mVBU6hlp0yorx+ZXGL2Y845SGD YFbyWP55pp1JJMwbafRt/d/MU+X7MeAdR87/ZN3eJRIg8JdIuyUQyAqWMFBBJq5bKQYnzS tJnobxFePhrPRxz1x+9sdqI+b979MaE= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-549-AXqNcXecP2a_H_RILENVXQ-1; Tue, 07 Jan 2025 15:40:11 -0500 X-MC-Unique: AXqNcXecP2a_H_RILENVXQ-1 X-Mimecast-MFC-AGG-ID: AXqNcXecP2a_H_RILENVXQ Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-7b6e241d34eso2276747385a.0 for ; Tue, 07 Jan 2025 12:40:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736282411; x=1736887211; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/Z9zMvty6z22PLVpM0GzhFMnUyCY+IlYCy3OrPbUsSM=; b=ImUmTfe/nnNbiqEx2eNVJyKcEc9tBNCLECOfXztFiSykxj+P2QZucMPgNdXnT6576m +YvLr9VG1WrLEARE5UW2toEIzLBHsmKhQwxNki/dRpGUP0ZOd3ljzb9A11Pl8lv4R01i u2G6ilT/7NBmIi9UHZ6WQJxo3KuEkN++PHiAwjU9NlAdDzbODabaUfnRTHeIsrJiFBY0 QIJrzj2BRk8vvilxBu9PFFJllNtAePyt+f6ctPoX/6tkoeC3l6brf9kSsrDoOTKFz/YI oyqG2Zha3xn6L+Tn4QFAjf76IMMJ4rS1NmDT53VzUIjMM6E00I/x7q39qsl2EtRPnt2d RY8g== X-Forwarded-Encrypted: i=1; AJvYcCVCgtLjvj4G04kPbzaQjajt83MnH952MBSCOdNWVpsuIjV1zqEFHaud5FVOr0QZ0p6SU2IT0R/Y+XaKDq8=@vger.kernel.org X-Gm-Message-State: AOJu0YwF6Aagk+9ZPEQbSi8gjqpiu0+3faBN0HtfG+EfK12EbpakQs0e 7rJDc8Rw9bbmml+epVbob8XsZ98X50uHGoQ9So70AjJpuRNFIcgf5YfnV5I0NkbmrZjXQvUCdGy MO/Q1HXrfNWa4aUtDbaZbg4I87+wmpbGASGchtN/kAN9ecE4bH/WCeaQAP0ubdw== X-Gm-Gg: ASbGnctnggeTbox0Oe9wBZcvNwBkRHZCO2UzBIHs/V4MvAJBZPGA2KcTQCX+d2Sh3VK REz32PBIBj8/aMBgZonD5wnQM3QjWXy1KOzUui+85rx0rko/GxnMVG1vtGAoqNr23JAPUJ2codF xcLyI92SVSTqr7lwl0/GZsZDj3HTnykj06BUFp+Jns1WrL5By4Jx8vND+DGJlkG2OveA6bE8IYs /dFWKa8smPAecDXOUiBt+U+ilfo/np5hyjYaeCpiKL5AeaRVNGNvSHHTXOp6ly09M32iyvtjk7v +kMu2WOUele9wen+pX51AQho7XMexoC6 X-Received: by 2002:a05:6214:27c2:b0:6d8:b3a7:75a5 with SMTP id 6a1803df08f44-6df9b2d50d7mr8913906d6.42.1736282411351; Tue, 07 Jan 2025 12:40:11 -0800 (PST) X-Google-Smtp-Source: AGHT+IHj1C6u68Y/+sXafpOSyDBghbB3mfdOGpS6Z/lZ5W8Owyk67iqxQBFKx0AO6ST9F8O901e9zA== X-Received: by 2002:a05:6214:27c2:b0:6d8:b3a7:75a5 with SMTP id 6a1803df08f44-6df9b2d50d7mr8913536d6.42.1736282410900; Tue, 07 Jan 2025 12:40:10 -0800 (PST) Received: from x1n.redhat.com (pool-99-254-114-190.cpe.net.cable.rogers.com. [99.254.114.190]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd181373f6sm184478306d6.62.2025.01.07.12.40.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jan 2025 12:40:10 -0800 (PST) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Breno Leitao , Rik van Riel , Muchun Song , Naoya Horiguchi , Roman Gushchin , Ackerley Tng , Andrew Morton , peterx@redhat.com, Oscar Salvador Subject: [PATCH v2 3/7] mm/hugetlb: Rename avoid_reserve to cow_from_owner Date: Tue, 7 Jan 2025 15:39:58 -0500 Message-ID: <20250107204002.2683356-4-peterx@redhat.com> X-Mailer: git-send-email 2.47.0 In-Reply-To: <20250107204002.2683356-1-peterx@redhat.com> References: <20250107204002.2683356-1-peterx@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The old name "avoid_reserve" can be too generic and can be used wrongly in the new call sites that want to allocate a hugetlb folio. It's confusing on two things: (1) whether one can opt-in to avoid global reservation, and (2) whether it should take more than one count. In reality, this flag is only used in an extremely hacky path, in an extremely hacky way in hugetlb CoW path only, and always use with 1 saying "skip global reservation". Rename the flag to avoid future abuse of this flag, making it a boolean so as to reflect its true representation that it's not a counter. To make it even harder to abuse, add a comment above the function to explain it. Signed-off-by: Peter Xu Reviewed-by: Oscar Salvador --- fs/hugetlbfs/inode.c | 2 +- include/linux/hugetlb.h | 4 ++-- mm/hugetlb.c | 33 ++++++++++++++++++++------------- 3 files changed, 23 insertions(+), 16 deletions(-) diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 62fb0cbc93ab..0fc179a59830 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -814,7 +814,7 @@ static long hugetlbfs_fallocate(struct file *file, int = mode, loff_t offset, * folios in these areas, we need to consume the reserves * to keep reservation accounting consistent. */ - folio =3D alloc_hugetlb_folio(&pseudo_vma, addr, 0); + folio =3D alloc_hugetlb_folio(&pseudo_vma, addr, false); if (IS_ERR(folio)) { mutex_unlock(&hugetlb_fault_mutex_table[hash]); error =3D PTR_ERR(folio); diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index 10faf42ca96a..49ec2362ce92 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -683,7 +683,7 @@ struct huge_bootmem_page { int isolate_or_dissolve_huge_page(struct page *page, struct list_head *lis= t); int replace_free_hugepage_folios(unsigned long start_pfn, unsigned long en= d_pfn); struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma, - unsigned long addr, int avoid_reserve); + unsigned long addr, bool cow_from_owner); struct folio *alloc_hugetlb_folio_nodemask(struct hstate *h, int preferred= _nid, nodemask_t *nmask, gfp_t gfp_mask, bool allow_alloc_fallback); @@ -1068,7 +1068,7 @@ static inline int replace_free_hugepage_folios(unsign= ed long start_pfn, =20 static inline struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma, unsigned long addr, - int avoid_reserve) + bool cow_from_owner) { return NULL; } diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 7be8c35d2a83..cdbc8914a9f7 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3008,8 +3008,15 @@ int replace_free_hugepage_folios(unsigned long start= _pfn, unsigned long end_pfn) return ret; } =20 +/* + * NOTE! "cow_from_owner" represents a very hacky usage only used in CoW + * faults of hugetlb private mappings on top of a non-page-cache folio (in + * which case even if there's a private vma resv map it won't cover such + * allocation). New call sites should (probably) never set it to true!! + * When it's set, the allocation will bypass all vma level reservations. + */ struct folio *alloc_hugetlb_folio(struct vm_area_struct *vma, - unsigned long addr, int avoid_reserve) + unsigned long addr, bool cow_from_owner) { struct hugepage_subpool *spool =3D subpool_vma(vma); struct hstate *h =3D hstate_vma(vma); @@ -3038,7 +3045,7 @@ struct folio *alloc_hugetlb_folio(struct vm_area_stru= ct *vma, * Allocations for MAP_NORESERVE mappings also need to be * checked against any subpool limit. */ - if (map_chg || avoid_reserve) { + if (map_chg || cow_from_owner) { gbl_chg =3D hugepage_subpool_get_pages(spool, 1); if (gbl_chg < 0) goto out_end_reservation; @@ -3046,7 +3053,7 @@ struct folio *alloc_hugetlb_folio(struct vm_area_stru= ct *vma, =20 /* If this allocation is not consuming a reservation, charge it now. */ - deferred_reserve =3D map_chg || avoid_reserve; + deferred_reserve =3D map_chg || cow_from_owner; if (deferred_reserve) { ret =3D hugetlb_cgroup_charge_cgroup_rsvd( idx, pages_per_huge_page(h), &h_cg); @@ -3071,7 +3078,7 @@ struct folio *alloc_hugetlb_folio(struct vm_area_stru= ct *vma, if (!folio) goto out_uncharge_cgroup; spin_lock_irq(&hugetlb_lock); - if (!avoid_reserve && vma_has_reserves(vma, gbl_chg)) { + if (!cow_from_owner && vma_has_reserves(vma, gbl_chg)) { folio_set_hugetlb_restore_reserve(folio); h->resv_huge_pages--; } @@ -3138,7 +3145,7 @@ struct folio *alloc_hugetlb_folio(struct vm_area_stru= ct *vma, hugetlb_cgroup_uncharge_cgroup_rsvd(idx, pages_per_huge_page(h), h_cg); out_subpool_put: - if (map_chg || avoid_reserve) + if (map_chg || cow_from_owner) hugepage_subpool_put_pages(spool, 1); out_end_reservation: vma_end_reservation(h, vma, addr); @@ -5369,7 +5376,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, st= ruct mm_struct *src, spin_unlock(src_ptl); spin_unlock(dst_ptl); /* Do not use reserve as it's private owned */ - new_folio =3D alloc_hugetlb_folio(dst_vma, addr, 0); + new_folio =3D alloc_hugetlb_folio(dst_vma, addr, false); if (IS_ERR(new_folio)) { folio_put(pte_folio); ret =3D PTR_ERR(new_folio); @@ -5823,7 +5830,7 @@ static vm_fault_t hugetlb_wp(struct folio *pagecache_= folio, struct hstate *h =3D hstate_vma(vma); struct folio *old_folio; struct folio *new_folio; - int outside_reserve =3D 0; + bool cow_from_owner =3D 0; vm_fault_t ret =3D 0; struct mmu_notifier_range range; =20 @@ -5886,7 +5893,7 @@ static vm_fault_t hugetlb_wp(struct folio *pagecache_= folio, */ if (is_vma_resv_set(vma, HPAGE_RESV_OWNER) && old_folio !=3D pagecache_folio) - outside_reserve =3D 1; + cow_from_owner =3D true; =20 folio_get(old_folio); =20 @@ -5895,7 +5902,7 @@ static vm_fault_t hugetlb_wp(struct folio *pagecache_= folio, * be acquired again before returning to the caller, as expected. */ spin_unlock(vmf->ptl); - new_folio =3D alloc_hugetlb_folio(vma, vmf->address, outside_reserve); + new_folio =3D alloc_hugetlb_folio(vma, vmf->address, cow_from_owner); =20 if (IS_ERR(new_folio)) { /* @@ -5905,7 +5912,7 @@ static vm_fault_t hugetlb_wp(struct folio *pagecache_= folio, * reliability, unmap the page from child processes. The child * may get SIGKILLed if it later faults. */ - if (outside_reserve) { + if (cow_from_owner) { struct address_space *mapping =3D vma->vm_file->f_mapping; pgoff_t idx; u32 hash; @@ -6156,7 +6163,7 @@ static vm_fault_t hugetlb_no_page(struct address_spac= e *mapping, goto out; } =20 - folio =3D alloc_hugetlb_folio(vma, vmf->address, 0); + folio =3D alloc_hugetlb_folio(vma, vmf->address, false); if (IS_ERR(folio)) { /* * Returning error will result in faulting task being @@ -6622,7 +6629,7 @@ int hugetlb_mfill_atomic_pte(pte_t *dst_pte, goto out; } =20 - folio =3D alloc_hugetlb_folio(dst_vma, dst_addr, 0); + folio =3D alloc_hugetlb_folio(dst_vma, dst_addr, false); if (IS_ERR(folio)) { ret =3D -ENOMEM; goto out; @@ -6664,7 +6671,7 @@ int hugetlb_mfill_atomic_pte(pte_t *dst_pte, goto out; } =20 - folio =3D alloc_hugetlb_folio(dst_vma, dst_addr, 0); + folio =3D alloc_hugetlb_folio(dst_vma, dst_addr, false); if (IS_ERR(folio)) { folio_put(*foliop); ret =3D -ENOMEM; --=20 2.47.0 From nobody Sat Feb 7 23:56:05 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 125B61F76A6 for ; Tue, 7 Jan 2025 20:40:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282417; cv=none; b=r2q2fJ8onRwPEN+NEZ/FMim0SUtHejOMRSMePuvXU5dU4+0+nmOCLqViBxXBVvc9hNWvTa52GVSXtTpCcn0922ulgtVcYdCs0+Z/TuCo/LqiSKRXLIVMe8iqf+DFXWqAEsv3/Q1Tj9meT2mfhHYEy2GlBFcy2TQffiaapOt2ABY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282417; c=relaxed/simple; bh=9xcVbiB8ttmCDuDhYwG383usFwZlNrlybeLaU00imC8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QCItPUOIuIA6iHW7/GL1/98VADlUtK4UXtPv0n4WWXulo1BLCTCO1M8n08GSZavHn1cURaoFrGiPWKZQl7ykp+tYfPoyClhx5TDIn1NgyzEEh3czPPNsfa727pqy0+atoH6r73YAXqhrnS9F8pNGOiYPF3DGKTjh/0zr85NqO/Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=BaUhc+aA; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BaUhc+aA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736282415; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yuwIwTLmWdhGbI1nIJskaIORTo+ctaybQQ0IHgYhnBg=; b=BaUhc+aAtO20vf26VoOAFQbxU9TLqZ4eFRSq9YMjfmuOUV2fSqnRoeB/ZfhgGiXmzWvHum IzFwik5T7qQq/6T5DoD3WpCcj2y3gtpz+wm8/QvYgj1Kd53uj3Wg7N8lylqcnafi+/mFax 6fGHuf+N75h42dlurv1Y0e9t+yD33No= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-94-ZEAb-GbwN62kDyqEJe4pcA-1; Tue, 07 Jan 2025 15:40:13 -0500 X-MC-Unique: ZEAb-GbwN62kDyqEJe4pcA-1 X-Mimecast-MFC-AGG-ID: ZEAb-GbwN62kDyqEJe4pcA Received: by mail-qv1-f71.google.com with SMTP id 6a1803df08f44-6d88c987fc7so269584686d6.3 for ; Tue, 07 Jan 2025 12:40:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736282413; x=1736887213; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yuwIwTLmWdhGbI1nIJskaIORTo+ctaybQQ0IHgYhnBg=; b=o84OrmI2EPLgbkiNdqbpqNiIFnfTrMGvMmonECPsziYS/d267zQagwKQOPyjSnzCvB MyggkpjfOYiBdgS9JIY7kn2/NyZfdDDAW6L3kuCDsnqSoySF9MkJrMzSWPLeNdL6IxXG 6EcfEqSValEwETnhPQHGO0PbtIr8+AB9LktnrtSE1tMyl6PV23vwveX28LkJf7NdXStI 7e0Ue6vY+aGTfjWCHded8QNVIo2FNT8oZtqwQyyP6z3jC9C0PnK/g78nYB/282Rx8eip Ppk1VOOXn2uWd+EmTmnpAVilA/LdubM8GOdYdA5nWEqYdhgbKbFrrDO9yC64htbzQjWa 8wCA== X-Forwarded-Encrypted: i=1; AJvYcCVuxZ5eRiEREZlkkyMH5H/rZ8QwdfzsknMx0Yr2IHwHr6JQ7FLD7s9Mk2DcqfKCuN0gYg1gQIJmDts7KKs=@vger.kernel.org X-Gm-Message-State: AOJu0Yyx4q2H5dbarmdXlnqikhzwP0ZlSdwwwsNXQlAQXJKXH2nvTp9c m7/tGepSAooJ1PZOvH4mUpOhOh+1mszf3h1SHHe2tN/eIWlGI9ppIPgrs5HRxVRLZnXQQ08IE+s RB+KmnX2mDplBgc8sGC3iXFwqbtbs0R819Kh+xFH0rIVLVsdzmmDZHF3nBM5lUA== X-Gm-Gg: ASbGnctYwWp7Y/GzH0Rg82Ja5dSlff9XGAKD0O/zJcPhd7vpJPgCNYMM5d2COnF3Vqa ki0/fIsXwvcX/RFzn9Ip7mnxTwXUoHeQRFwmTEKxx79ZJ9hjyV/i3UXSPTwMpm7KskYiHG4U+E4 HhSS5BhFWHzzhgTywDJfUE2vVKTrq+sM9uvOKlt8evYLMNW7idyjCdwp65JGBQHxnGLOJqa1fE0 DnEcqBJQ/aD+ZKy8++YDX84nfsd7/BjpLqrK8RkQWN6eEGX9oFKJctvnUskLLel7K/uGnHsmX38 j0reZDC+EUFIoR6y+U4BC2JTJIuyu0o8 X-Received: by 2002:a05:6214:2586:b0:6d8:883b:142a with SMTP id 6a1803df08f44-6df9b1b4fdfmr9241086d6.2.1736282413169; Tue, 07 Jan 2025 12:40:13 -0800 (PST) X-Google-Smtp-Source: AGHT+IFsIwbZ8AHU5wiq8R2gE/O6m3JMATzJlnU9LbxD3qmGV4Q8ausp9Ssq2fF5qI6zbJ5x9oBK+A== X-Received: by 2002:a05:6214:2586:b0:6d8:883b:142a with SMTP id 6a1803df08f44-6df9b1b4fdfmr9240726d6.2.1736282412797; Tue, 07 Jan 2025 12:40:12 -0800 (PST) Received: from x1n.redhat.com (pool-99-254-114-190.cpe.net.cable.rogers.com. [99.254.114.190]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd181373f6sm184478306d6.62.2025.01.07.12.40.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jan 2025 12:40:11 -0800 (PST) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Breno Leitao , Rik van Riel , Muchun Song , Naoya Horiguchi , Roman Gushchin , Ackerley Tng , Andrew Morton , peterx@redhat.com, Oscar Salvador Subject: [PATCH v2 4/7] mm/hugetlb: Clean up map/global resv accounting when allocate Date: Tue, 7 Jan 2025 15:39:59 -0500 Message-ID: <20250107204002.2683356-5-peterx@redhat.com> X-Mailer: git-send-email 2.47.0 In-Reply-To: <20250107204002.2683356-1-peterx@redhat.com> References: <20250107204002.2683356-1-peterx@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" alloc_hugetlb_folio() isn't a function easy to read, especially on reservation accountings for either VMA or globally (majorly, spool only). The 1st complexity lies in the special private CoW path, aka, cow_from_owner=3Dtrue case. The 2nd complexity may be the confusing updates of gbl_chg after it's set once, which looks like they can change anytime on the fly. Logically, cow_from_user is only about vma reservation. We could already decouple the flag and consolidate it into map charge flag very early. Then we don't need to keep checking the CoW special flag every time. This patch does it by making map_chg a tri-state flag. Tri-state needed is unfortunate, and it's because currently vma_needs_reservation() has a side effect internally, that it must be followed by either a end() or commit(). We keep the same semantic as before on one thing: "if (map_chg)" means we need a separate per-vma resv count. It keeps most of the old code like before untouched with the new enum. After this patch, we take these steps to decide these variables, hopefully slightly easier to follow: - First, decide map_chg. This will take cow_from_owner into account, once and for all. It's about whether we could take a resv count from the vma, no matter it's shared, private, etc. - Then, decide gbl_chg. The only diff here is spool, comparing to map_chg. Now only update each flag once and for all, instead of keep any of them flipping which can be very hard to follow. With cow_from_owner merged into map_chg, we could remove quite a few such checks all over. Side benefit of such is that we can get rid of one more confusing flag, which is deferred_reserve. Cleanup the comments a bit too. E.g., MAP_NORESERVE may not need to check against spool limit, AFAIU, if it's on a shared mapping, and if the page cache folio has its inode's resv map available (in which case map_chg would have been set zero, hence the code should be correct, not the comment). There's one trivial detail that needs attention that this patch touched, which is this check right after vma_commit_reservation(): if (map_chg > map_commit) It changes to: if (unlikely(map_chg =3D=3D MAP_CHG_NEEDED && retval =3D=3D 0)) It should behave the same like before, because previously the only way to make "map_chg > map_commit" happen is map_chg=3D1 && map_commit=3D0. That's exactly the rewritten line. Meanwhile, either commit() or end() will need to be skipped if ENFORCE, to keep the old behavior. Even though it looks a lot changed, but no functional change expected. Signed-off-by: Peter Xu --- mm/hugetlb.c | 110 +++++++++++++++++++++++++++++++++++---------------- 1 file changed, 77 insertions(+), 33 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index cdbc8914a9f7..b8a849fe1531 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2970,6 +2970,25 @@ int isolate_or_dissolve_huge_page(struct page *page,= struct list_head *list) return ret; } =20 +typedef enum { + /* + * For either 0/1: we checked the per-vma resv map, and one resv + * count either can be reused (0), or an extra needed (1). + */ + MAP_CHG_REUSE =3D 0, + MAP_CHG_NEEDED =3D 1, + /* + * Cannot use per-vma resv count can be used, hence a new resv + * count is enforced. + * + * NOTE: This is mostly identical to MAP_CHG_NEEDED, except + * that currently vma_needs_reservation() has an unwanted side + * effect to either use end() or commit() to complete the + * transaction. Hence it needs to differenciate from NEEDED. + */ + MAP_CHG_ENFORCED =3D 2, +} map_chg_state; + /* * replace_free_hugepage_folios - Replace free hugepage folios in a given= pfn * range with new folios. @@ -3021,40 +3040,59 @@ struct folio *alloc_hugetlb_folio(struct vm_area_st= ruct *vma, struct hugepage_subpool *spool =3D subpool_vma(vma); struct hstate *h =3D hstate_vma(vma); struct folio *folio; - long map_chg, map_commit; - long gbl_chg; + long retval, gbl_chg; + map_chg_state map_chg; int ret, idx; struct hugetlb_cgroup *h_cg =3D NULL; - bool deferred_reserve; gfp_t gfp =3D htlb_alloc_mask(h) | __GFP_RETRY_MAYFAIL; =20 idx =3D hstate_index(h); - /* - * Examine the region/reserve map to determine if the process - * has a reservation for the page to be allocated. A return - * code of zero indicates a reservation exists (no change). - */ - map_chg =3D gbl_chg =3D vma_needs_reservation(h, vma, addr); - if (map_chg < 0) - return ERR_PTR(-ENOMEM); + + /* Whether we need a separate per-vma reservation? */ + if (cow_from_owner) { + /* + * Special case! Since it's a CoW on top of a reserved + * page, the private resv map doesn't count. So it cannot + * consume the per-vma resv map even if it's reserved. + */ + map_chg =3D MAP_CHG_ENFORCED; + } else { + /* + * Examine the region/reserve map to determine if the process + * has a reservation for the page to be allocated. A return + * code of zero indicates a reservation exists (no change). + */ + retval =3D vma_needs_reservation(h, vma, addr); + if (retval < 0) + return ERR_PTR(-ENOMEM); + map_chg =3D retval ? MAP_CHG_NEEDED : MAP_CHG_REUSE; + } =20 /* + * Whether we need a separate global reservation? + * * Processes that did not create the mapping will have no * reserves as indicated by the region/reserve map. Check * that the allocation will not exceed the subpool limit. - * Allocations for MAP_NORESERVE mappings also need to be - * checked against any subpool limit. + * Or if it can get one from the pool reservation directly. */ - if (map_chg || cow_from_owner) { + if (map_chg) { gbl_chg =3D hugepage_subpool_get_pages(spool, 1); if (gbl_chg < 0) goto out_end_reservation; + } else { + /* + * If we have the vma reservation ready, no need for extra + * global reservation. + */ + gbl_chg =3D 0; } =20 - /* If this allocation is not consuming a reservation, charge it now. + /* + * If this allocation is not consuming a per-vma reservation, + * charge the hugetlb cgroup now. */ - deferred_reserve =3D map_chg || cow_from_owner; - if (deferred_reserve) { + if (map_chg) { ret =3D hugetlb_cgroup_charge_cgroup_rsvd( idx, pages_per_huge_page(h), &h_cg); if (ret) @@ -3078,7 +3116,7 @@ struct folio *alloc_hugetlb_folio(struct vm_area_stru= ct *vma, if (!folio) goto out_uncharge_cgroup; spin_lock_irq(&hugetlb_lock); - if (!cow_from_owner && vma_has_reserves(vma, gbl_chg)) { + if (vma_has_reserves(vma, gbl_chg)) { folio_set_hugetlb_restore_reserve(folio); h->resv_huge_pages--; } @@ -3091,7 +3129,7 @@ struct folio *alloc_hugetlb_folio(struct vm_area_stru= ct *vma, /* If allocation is not consuming a reservation, also store the * hugetlb_cgroup pointer on the page. */ - if (deferred_reserve) { + if (map_chg) { hugetlb_cgroup_commit_charge_rsvd(idx, pages_per_huge_page(h), h_cg, folio); } @@ -3100,26 +3138,31 @@ struct folio *alloc_hugetlb_folio(struct vm_area_st= ruct *vma, =20 hugetlb_set_folio_subpool(folio, spool); =20 - map_commit =3D vma_commit_reservation(h, vma, addr); - if (unlikely(map_chg > map_commit)) { + if (map_chg !=3D MAP_CHG_ENFORCED) { + /* commit() is only needed if the map_chg is not enforced */ + retval =3D vma_commit_reservation(h, vma, addr); /* + * Check for possible race conditions. When it happens.. * The page was added to the reservation map between * vma_needs_reservation and vma_commit_reservation. * This indicates a race with hugetlb_reserve_pages. * Adjust for the subpool count incremented above AND - * in hugetlb_reserve_pages for the same page. Also, + * in hugetlb_reserve_pages for the same page. Also, * the reservation count added in hugetlb_reserve_pages * no longer applies. */ - long rsv_adjust; + if (unlikely(map_chg =3D=3D MAP_CHG_NEEDED && retval =3D=3D 0)) { + long rsv_adjust; =20 - rsv_adjust =3D hugepage_subpool_put_pages(spool, 1); - hugetlb_acct_memory(h, -rsv_adjust); - if (deferred_reserve) { - spin_lock_irq(&hugetlb_lock); - hugetlb_cgroup_uncharge_folio_rsvd(hstate_index(h), - pages_per_huge_page(h), folio); - spin_unlock_irq(&hugetlb_lock); + rsv_adjust =3D hugepage_subpool_put_pages(spool, 1); + hugetlb_acct_memory(h, -rsv_adjust); + if (map_chg) { + spin_lock_irq(&hugetlb_lock); + hugetlb_cgroup_uncharge_folio_rsvd( + hstate_index(h), pages_per_huge_page(h), + folio); + spin_unlock_irq(&hugetlb_lock); + } } } =20 @@ -3141,14 +3184,15 @@ struct folio *alloc_hugetlb_folio(struct vm_area_st= ruct *vma, out_uncharge_cgroup: hugetlb_cgroup_uncharge_cgroup(idx, pages_per_huge_page(h), h_cg); out_uncharge_cgroup_reservation: - if (deferred_reserve) + if (map_chg) hugetlb_cgroup_uncharge_cgroup_rsvd(idx, pages_per_huge_page(h), h_cg); out_subpool_put: - if (map_chg || cow_from_owner) + if (map_chg) hugepage_subpool_put_pages(spool, 1); out_end_reservation: - vma_end_reservation(h, vma, addr); + if (map_chg !=3D MAP_CHG_ENFORCED) + vma_end_reservation(h, vma, addr); return ERR_PTR(-ENOSPC); } =20 --=20 2.47.0 From nobody Sat Feb 7 23:56:05 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 329AF1F669F for ; Tue, 7 Jan 2025 20:40:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282420; cv=none; b=gx4+Jho1ZUhvM/NjIcYBBApDrFAmcu1YdZtHK8H8biwYzk14B5bUPdF7ftI/oIaa9AGf7GsWswaQRXlrNhlrXodPq4v/nLGG0VIXpMSK854Chc4HOl5RRGl+YAl6gF2TKK/2ktKHs7ea8DoqNWW8nbSTrIxU6KdX5TZAZEbutBA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282420; c=relaxed/simple; bh=miJnVFlp+8lFYrNECV1q4UvY9H2N0nPtMDXK6Osx2j0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GXlVVqvPjmq/e8hayxPVW4oGzn3g9jYHQhLLDqoZgWdoMz/WFcUruL5Z3CQWMW4C7z51wcOBIXiCkdpV5Fufrg3x17c7NIrRmYKc8s1uURfaPEYwfkA5lOdymvICkmdVpjSH6XmdyBDj4fo671XCORZ4ddTHqdr0rL5ne0of2K4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=MqWiJpnR; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="MqWiJpnR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736282417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FeRSwArockADk7XuGGq52WKujX3Jyjof3FZOrhLMA7I=; b=MqWiJpnRWgTE70hM91MbTq/w91PVMzfcAHnUpGhX610BLb0f7lJCKTjCDz9GrnFHj3szyj EgbEGtG1w/3t4nFe3Hw1txh9kXJUK5VdaelDQGBgV81k+IMT1BAIpANPxpi8KsWGXu9R3G Y4fbyROrqeuYua+I5tH6uABqF1IbPLI= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-437-maJF6XPaOfCarlWQw9x9Lw-1; Tue, 07 Jan 2025 15:40:16 -0500 X-MC-Unique: maJF6XPaOfCarlWQw9x9Lw-1 X-Mimecast-MFC-AGG-ID: maJF6XPaOfCarlWQw9x9Lw Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-6d8f0b1023bso179410986d6.0 for ; Tue, 07 Jan 2025 12:40:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736282415; x=1736887215; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FeRSwArockADk7XuGGq52WKujX3Jyjof3FZOrhLMA7I=; b=foggBA15z2A4CNCAcOKFaYVkKYpVbsWq7ds23LO33BbIrb2dr9WyoHS72ExWY2D51O 3Q7juVl+LahOQpTrxafKOOMmyEm5PUkBY9V9AH6z5yoOK8LjCO/l8Kuxp20o3ous0W3Q qZjX0j5AnwQFDwhEv9AHo/9kgU/5670MfjO4cSCgIP2Cl5nezUq/MMqVEVjWfVnxxqnt Y0/hM+/UmZWrgu2Qh5a1/rXUBqvVQvtpt1wo4PSgUiZiT9PBA16U+/+4xMRdNObgVm1Z w3reBQMWZOYvAXrmMCRg+6sCavxkXUksIlTx4DzLG/yBdIkR+uHQ/vPfJxCTNF8xE9G2 yfeA== X-Forwarded-Encrypted: i=1; AJvYcCXL9DTZcKf91DYDL9lvKdRiiJdDViyfwDDRmRq4nkXp3jbPkM8hjPnUZIiLfR2erDHairsb19W3yg0m7Jk=@vger.kernel.org X-Gm-Message-State: AOJu0YwykqTsYmtq5i6xbQLXWXf8tUOLlLBZPCRYa8IX6fbYup62dDcl BJlDMfEgK4B24DIQhAJm0iDmEXt8mOUyiyDFACuHCioLnqWIkenzvGYWZsJZKFxLjePCglAGJzB hkrFt3A6cfGMbTr7otCre+8rYxMPsI6yN7lbNlPjchn9CyfdRYYtyJPj3/kt3og== X-Gm-Gg: ASbGncuXwQ3V4ZAN4krAkA/K71VzBfbTUa30Ugw9bLvB/7kPqJwAHjPUYG16r3EzQmV /jptEHYYaVCb3y8WVaGXO8MDJ+smcknyz6cKDZ5LW8Cwdnffmq5csc8GV5uZ1Ls0BQqEQAzPuWY OSzieEb8jrzr+RTpa5aDZzRrJVTo4eh5abpYozpqzpgKjKZZMxPEkiJNZYU4pZ3NTCMjzvrU3aY PnGUHo0SzSYGvAiTV0bV7Uc9sCNM4KysuCNOuWjRcVx9QJCo9dNoUv3sNNHzsfyhzGhf7Wy3e5v er/WQkxSZuNeYNsVGQY2BVVToNG8uO54 X-Received: by 2002:a05:6214:434a:b0:6d8:cff9:f373 with SMTP id 6a1803df08f44-6df9b2d1a40mr7580956d6.30.1736282415440; Tue, 07 Jan 2025 12:40:15 -0800 (PST) X-Google-Smtp-Source: AGHT+IE3MtP6+dWvdpGsDlM1wGqTR7s1w0fblu3/xx93mfYpEOm6U5pVW/zHRBSeKXgOBBACpJiRAA== X-Received: by 2002:a05:6214:434a:b0:6d8:cff9:f373 with SMTP id 6a1803df08f44-6df9b2d1a40mr7580606d6.30.1736282415027; Tue, 07 Jan 2025 12:40:15 -0800 (PST) Received: from x1n.redhat.com (pool-99-254-114-190.cpe.net.cable.rogers.com. [99.254.114.190]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd181373f6sm184478306d6.62.2025.01.07.12.40.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jan 2025 12:40:13 -0800 (PST) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Breno Leitao , Rik van Riel , Muchun Song , Naoya Horiguchi , Roman Gushchin , Ackerley Tng , Andrew Morton , peterx@redhat.com, Oscar Salvador Subject: [PATCH v2 5/7] mm/hugetlb: Simplify vma_has_reserves() Date: Tue, 7 Jan 2025 15:40:00 -0500 Message-ID: <20250107204002.2683356-6-peterx@redhat.com> X-Mailer: git-send-email 2.47.0 In-Reply-To: <20250107204002.2683356-1-peterx@redhat.com> References: <20250107204002.2683356-1-peterx@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" vma_has_reserves() is a helper "trying" to know whether the vma should consume one reservation when allocating the hugetlb folio. However it's not clear on why we need such complexity, as such information is already represented in the "chg" variable. From alloc_hugetlb_folio() context, "chg" (or in the function's context, "gbl_chg") is defined as: - If gbl_chg=3D1, the allocation cannot reuse an existing reservation - If gbl_chg=3D0, the allocation should reuse an existing reservation Firstly, map_chg is defined as following, to cover all cases of hugetlb reservation scenarios (mostly, via vma_needs_reservation(), but cow_from_owner is an outlier): CONDITION HAS RESERVATION? =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - SHARED: always check against per-inode resv_map (ignore NONRESERVE) - If resv exists =3D=3D> YES [1] - If not =3D=3D> NO [2] - PRIVATE: complicated... - Request came from a CoW from owner resv map =3D=3D> NO [3] (when cow_from_owner=3D=3Dtrue) - If does not own a resv_map at all.. =3D=3D> NO [4] (examples: VM_NORESERVE, private fork()) - If owns a resv_map, but resv donsn't exists =3D=3D> NO [5] - If owns a resv_map, and resv exists =3D=3D> YES [6] Further on, gbl_chg considered spool setup, so that is a decision based on all the context. If we look at vma_has_reserves(), it almost does check that has already been processed by map_chg accounting (I marked each return value to the case above): static bool vma_has_reserves(struct vm_area_struct *vma, long chg) { if (vma->vm_flags & VM_NORESERVE) { if (vma->vm_flags & VM_MAYSHARE && chg =3D=3D 0) return true; =3D=3D> [1] else return false; =3D=3D> [2] or [4] } if (vma->vm_flags & VM_MAYSHARE) { if (chg) return false; =3D=3D> [2] else return true; =3D=3D> [1] } if (is_vma_resv_set(vma, HPAGE_RESV_OWNER)) { if (chg) return false; =3D=3D> [5] else return true; =3D=3D> [6] } return false; =3D=3D> [4] } It didn't check [3], but [3] case was actually already covered now by the "chg" / "gbl_chg" / "map_chg" calculations. In short, vma_has_reserves() doesn't provide anything more than return "!chg".. so just simplify all the things. There're a lot of comments describing truncation races, IIUC there should have no race as long as map_chg is properly done. Signed-off-by: Peter Xu --- mm/hugetlb.c | 67 ++++++---------------------------------------------- 1 file changed, 7 insertions(+), 60 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index b8a849fe1531..5ec079f32f44 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1247,66 +1247,13 @@ void clear_vma_resv_huge_pages(struct vm_area_struc= t *vma) } =20 /* Returns true if the VMA has associated reserve pages */ -static bool vma_has_reserves(struct vm_area_struct *vma, long chg) +static bool vma_has_reserves(long chg) { - if (vma->vm_flags & VM_NORESERVE) { - /* - * This address is already reserved by other process(chg =3D=3D 0), - * so, we should decrement reserved count. Without decrementing, - * reserve count remains after releasing inode, because this - * allocated page will go into page cache and is regarded as - * coming from reserved pool in releasing step. Currently, we - * don't have any other solution to deal with this situation - * properly, so add work-around here. - */ - if (vma->vm_flags & VM_MAYSHARE && chg =3D=3D 0) - return true; - else - return false; - } - - /* Shared mappings always use reserves */ - if (vma->vm_flags & VM_MAYSHARE) { - /* - * We know VM_NORESERVE is not set. Therefore, there SHOULD - * be a region map for all pages. The only situation where - * there is no region map is if a hole was punched via - * fallocate. In this case, there really are no reserves to - * use. This situation is indicated if chg !=3D 0. - */ - if (chg) - return false; - else - return true; - } - /* - * Only the process that called mmap() has reserves for - * private mappings. + * Now "chg" has all the conditions considered for whether we + * should use an existing reservation. */ - if (is_vma_resv_set(vma, HPAGE_RESV_OWNER)) { - /* - * Like the shared case above, a hole punch or truncate - * could have been performed on the private mapping. - * Examine the value of chg to determine if reserves - * actually exist or were previously consumed. - * Very Subtle - The value of chg comes from a previous - * call to vma_needs_reserves(). The reserve map for - * private mappings has different (opposite) semantics - * than that of shared mappings. vma_needs_reserves() - * has already taken this difference in semantics into - * account. Therefore, the meaning of chg is the same - * as in the shared case above. Code could easily be - * combined, but keeping it separate draws attention to - * subtle differences. - */ - if (chg) - return false; - else - return true; - } - - return false; + return chg =3D=3D 0; } =20 static void enqueue_hugetlb_folio(struct hstate *h, struct folio *folio) @@ -1407,7 +1354,7 @@ static struct folio *dequeue_hugetlb_folio_vma(struct= hstate *h, * have no page reserves. This check ensures that reservations are * not "stolen". The child may still get SIGKILLed */ - if (!vma_has_reserves(vma, chg) && !available_huge_pages(h)) + if (!vma_has_reserves(chg) && !available_huge_pages(h)) goto err; =20 gfp_mask =3D htlb_alloc_mask(h); @@ -1425,7 +1372,7 @@ static struct folio *dequeue_hugetlb_folio_vma(struct= hstate *h, folio =3D dequeue_hugetlb_folio_nodemask(h, gfp_mask, nid, nodemask); =20 - if (folio && vma_has_reserves(vma, chg)) { + if (folio && vma_has_reserves(chg)) { folio_set_hugetlb_restore_reserve(folio); h->resv_huge_pages--; } @@ -3116,7 +3063,7 @@ struct folio *alloc_hugetlb_folio(struct vm_area_stru= ct *vma, if (!folio) goto out_uncharge_cgroup; spin_lock_irq(&hugetlb_lock); - if (vma_has_reserves(vma, gbl_chg)) { + if (vma_has_reserves(gbl_chg)) { folio_set_hugetlb_restore_reserve(folio); h->resv_huge_pages--; } --=20 2.47.0 From nobody Sat Feb 7 23:56:05 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7DEAA1F8668 for ; Tue, 7 Jan 2025 20:40:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282422; cv=none; b=P3Ybgwf4IKYvb2fVBeBOP2f7vkPfprKO7CPqWksSK5tRGmSiCrtBq9JWuqsCli6fjz4rJG9aqb8/3LHkFZDJygzt/i3G824nJNA5f8M8iwdCE7l9obbkOqh74B2AIAJITxcITcOhMoU1oRp8Bh2SSnD+i1grUNFUxuNjqBOUwY4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282422; c=relaxed/simple; bh=ChUJyn1ZvhYPvEL6LLT7uuYrXRhH1sWx06AedmXBNWE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gQI+avki20qffMws313YxuDUjIZ/HnaZSCtk9EqtZZhygNdUrroxtPrjDTR+W6l6LzNnbnoaUQiXDAAoOJ4SY2wUzo49W5BVcwt5IswGcDwD0IlcnjUFLSqGIArD7lGv5HVhXWq6gVEU17Hl5MrviJQgH17SNSt4EZkEVNquqjM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=eq5zGFPG; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="eq5zGFPG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736282419; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Tqf5zDG9MEFYyrwcky7SImgBB1+VbhDKSE1RWjLi9H0=; b=eq5zGFPG8quXNUlELHwuy93ZeoP9j1VjyF+1lhIZOIsW39B7DY2FcXK7tv0L5q/kBCSM3d +aCQPKv6TTM/csWksP7V1J6CvW4KJ3io/fAn4fAiS5UyLEzUN57uRouEPwBy0HvmHgm6We 5bl0SwEr7WswF3kLBaRF65K/RVjosws= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-13-CBi5-ArQOG6N9WcY2YPUhw-1; Tue, 07 Jan 2025 15:40:17 -0500 X-MC-Unique: CBi5-ArQOG6N9WcY2YPUhw-1 X-Mimecast-MFC-AGG-ID: CBi5-ArQOG6N9WcY2YPUhw Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-6d8f6903d2eso261248686d6.2 for ; Tue, 07 Jan 2025 12:40:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736282417; x=1736887217; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Tqf5zDG9MEFYyrwcky7SImgBB1+VbhDKSE1RWjLi9H0=; b=UKarA355xhXZIVl5h8h0cSZY4CP1m/BUpgs4hEM69toIhtUUBMWSTQ3VFPuO10HwJn LrApI2zI6ZKpmcNsRyQCPQN8GEj3PlDeYXPMmIn6qHjP7B/tMBjh2SQbTJ9Y5b1Oz/8t uXKCqaH+Vo+EQm7/GAl+qRKMFCivr2YRHYHxANkyeFg2Lt8lj26PSV954X0m5Q2aLeqc 1saWH+d/mWBhXF4eBzFrUKaQBma94BMv8Xkl00maHW3jioq8p/pffs4+NZug2zx0mfNY ckU1G0l7+QV2Ihz3XtfUmwK/cjRjG0gS5Q3C0BR522VvpBpHZk5KsLEEmfIETwP6YJPQ vHxg== X-Forwarded-Encrypted: i=1; AJvYcCXMBOgmHVphwYVOTSg/RQsl1jeejWdvqZn1oC/G2lSpyZCur4yg9EcIoSHeh5MLlV8jWuUTCDvLAkXqPuI=@vger.kernel.org X-Gm-Message-State: AOJu0YzxwkuwTHLgH3TckMSS47fSdJefBHrD39uAgbnFaX9+IYQXmeVu JK4EjTDY8zIgH9nP9RMD55vWe7ACA9OliFHOVjW/E1qJspa/D8bp+VBXgneSYeAEndC762AtMkm 7n+s2MpUX6Zip/QnvkHbp+vdDc6fl6aR8nxDxEcrG4zhak6tHKzBChplap1Sr1A== X-Gm-Gg: ASbGncv7Q0hW/KuIkLtB+VDgqUlx1Z1zb6m3joUnstZ0eZtmZnvLXBq9j5/rXfcJWFv tctAZdjxoBqoEsNEVcJoHoDv66t2COTJxi4zi0AY/22HEGB45A3nw97NGgmLwFMmitl61kjUeAQ shfbJOL/+iMKL9o9EkxMP7Z+0one8mmB3oFHxVypm5Lke6LB2J3eNSjpKUpaMjjdmZDmDxo9ZEf P6VwaSV2/45qHXReXl9KLro1PT5vthq4oIL+PKbiT7zpZBm/qL/+VqFQzIcRoG0V+Tc99Bq2kZw 480QpvFUUw2hEiKA6IXCeOKGL50jP5eg X-Received: by 2002:ad4:5b8d:0:b0:6d8:a091:4f5c with SMTP id 6a1803df08f44-6df9b2ddae0mr7742876d6.33.1736282417316; Tue, 07 Jan 2025 12:40:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IEO5EEzKoo4b8+dAKo+7OX2D+ltSzCgzDPjxXEVdIBKDurWSenXTIIEcfAQvgTlo32tr/LGYA== X-Received: by 2002:ad4:5b8d:0:b0:6d8:a091:4f5c with SMTP id 6a1803df08f44-6df9b2ddae0mr7742556d6.33.1736282416972; Tue, 07 Jan 2025 12:40:16 -0800 (PST) Received: from x1n.redhat.com (pool-99-254-114-190.cpe.net.cable.rogers.com. [99.254.114.190]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd181373f6sm184478306d6.62.2025.01.07.12.40.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jan 2025 12:40:16 -0800 (PST) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Breno Leitao , Rik van Riel , Muchun Song , Naoya Horiguchi , Roman Gushchin , Ackerley Tng , Andrew Morton , peterx@redhat.com, Oscar Salvador Subject: [PATCH v2 6/7] mm/hugetlb: Drop vma_has_reserves() Date: Tue, 7 Jan 2025 15:40:01 -0500 Message-ID: <20250107204002.2683356-7-peterx@redhat.com> X-Mailer: git-send-email 2.47.0 In-Reply-To: <20250107204002.2683356-1-peterx@redhat.com> References: <20250107204002.2683356-1-peterx@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" After the previous cleanup, vma_has_reserves() is mostly an empty helper except that it says "use reserve count" is inverted meaning from "needs a global reserve count", which is still true. To avoid confusions on having two inverted ways to ask the same question, always use the gbl_chg everywhere, and drop the function. When at it, rename "chg" to "gbl_chg" in dequeue_hugetlb_folio_vma(). It might be helpful for readers to see that the "chg" here is the global reserve count, not the vma resv count. Signed-off-by: Peter Xu --- mm/hugetlb.c | 23 ++++++----------------- 1 file changed, 6 insertions(+), 17 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 5ec079f32f44..922d57e2413a 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1246,16 +1246,6 @@ void clear_vma_resv_huge_pages(struct vm_area_struct= *vma) hugetlb_dup_vma_private(vma); } =20 -/* Returns true if the VMA has associated reserve pages */ -static bool vma_has_reserves(long chg) -{ - /* - * Now "chg" has all the conditions considered for whether we - * should use an existing reservation. - */ - return chg =3D=3D 0; -} - static void enqueue_hugetlb_folio(struct hstate *h, struct folio *folio) { int nid =3D folio_nid(folio); @@ -1341,7 +1331,7 @@ static unsigned long available_huge_pages(struct hsta= te *h) =20 static struct folio *dequeue_hugetlb_folio_vma(struct hstate *h, struct vm_area_struct *vma, - unsigned long address, long chg) + unsigned long address, long gbl_chg) { struct folio *folio =3D NULL; struct mempolicy *mpol; @@ -1350,11 +1340,10 @@ static struct folio *dequeue_hugetlb_folio_vma(stru= ct hstate *h, int nid; =20 /* - * A child process with MAP_PRIVATE mappings created by their parent - * have no page reserves. This check ensures that reservations are - * not "stolen". The child may still get SIGKILLed + * gbl_chg=3D=3D1 means the allocation requires a new page that was not + * reserved before. Making sure there's at least one free page. */ - if (!vma_has_reserves(chg) && !available_huge_pages(h)) + if (gbl_chg && !available_huge_pages(h)) goto err; =20 gfp_mask =3D htlb_alloc_mask(h); @@ -1372,7 +1361,7 @@ static struct folio *dequeue_hugetlb_folio_vma(struct= hstate *h, folio =3D dequeue_hugetlb_folio_nodemask(h, gfp_mask, nid, nodemask); =20 - if (folio && vma_has_reserves(chg)) { + if (folio && !gbl_chg) { folio_set_hugetlb_restore_reserve(folio); h->resv_huge_pages--; } @@ -3063,7 +3052,7 @@ struct folio *alloc_hugetlb_folio(struct vm_area_stru= ct *vma, if (!folio) goto out_uncharge_cgroup; spin_lock_irq(&hugetlb_lock); - if (vma_has_reserves(gbl_chg)) { + if (!gbl_chg) { folio_set_hugetlb_restore_reserve(folio); h->resv_huge_pages--; } --=20 2.47.0 From nobody Sat Feb 7 23:56:05 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8AF471F8683 for ; Tue, 7 Jan 2025 20:40:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282423; cv=none; b=XzIO+tbI2eVFgasFXF68YTiZk/zgupWFWWkh4e0LXP2KHH2/ulQM2GSObJcx4SFR/RYyNBNicYncM/qozgCAanMV3yQ6aePReMxddFvia1Lr0YFu3t2NPK66hC0h0Gni70yB6phmXDID8XDHUY0YXCm2vrxl8BuCiOFwcnRypJg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282423; c=relaxed/simple; bh=jsqM6u/y4O8sZhbKgXb0JpfUTRY92+S5FEjDF4D7UAY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dgpyyUe2GJB9KbPhOMhkOckW4LktgCGQ/BlCNo8h2p+Nwez3dr2yVan55DTlmlIH7EEqqdw3q8MFpaHLJ2FsTtkjUI9mbJCt/nCyctbLXzKfyoXUjNlG/7oDYmSEK59hnLF/+CAxFYV0/+rTxb7QGUBw1PI6Du7pDyk8t9cKqKw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=a5R81oWc; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="a5R81oWc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736282420; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/+nsOFPsTLzwi0UWOyyE5ZOk1n60MXP64Ncf3blKR+I=; b=a5R81oWcymzm++EjDZfjn8SXfPFaAv9s2umpNkisoQvQfAxHVUJPpg4I8OtxcHW3tY/uda 8E68+eeBfTly/hiQyglgi82K9vbUO77GlqA14C+Nt2BCpQS3odavo0MlTYCsHicLkIxsMH faP/pXCXiLm8QX5Mo5WQWcn212pZzSI= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-104-uUWLeflHMkKcvxRrntf8Ig-1; Tue, 07 Jan 2025 15:40:19 -0500 X-MC-Unique: uUWLeflHMkKcvxRrntf8Ig-1 X-Mimecast-MFC-AGG-ID: uUWLeflHMkKcvxRrntf8Ig Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-6d8f78fdad0so241925026d6.2 for ; Tue, 07 Jan 2025 12:40:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736282419; x=1736887219; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/+nsOFPsTLzwi0UWOyyE5ZOk1n60MXP64Ncf3blKR+I=; b=ErCKEYyWhKmgk0UcKJ8j6NgQ1s4+hsfYY1s15Ey4DL+01kZpLR9fUConCbRCDVebi6 tRXfphHmOGEnmqy9KFIviCzISBilbuTUVk+gaHj77j0foek2LFpSn81KiORHAyxpye3T X1H+wc32QT6IIqZ9B5MsQyv8gIBi4OoEj+wpSGJ0HsnTrm4w4lSEyJXphsaPluvbxLLy 0mmqyjSyN7OJO7p/HBGqNp1kqyv5wVle/6pbAWVuA35TTL+Bn/2mNi8SDm/vkoOiattW vO1Hw1h/sZF8wp1G3Iqzoq8/jmCM1nQWHOXrCpUXvRTPCLKTpoXKFRvUmPjZ3WlRnTnC 6RIQ== X-Forwarded-Encrypted: i=1; AJvYcCVvGqKN2Y85xns9NsmBNdEPdrRp263s8SrbyxdCmyp2jB8cinTrkZOBvuCqCW/+K9ZqAMLpLp03q69Urtk=@vger.kernel.org X-Gm-Message-State: AOJu0YzKGCFG4+g+3K5ubPmNpjT6+bh19N/I03mJIgTCx/t0AJoFPXWy 6TfGXcymJRi3jcXqlV8uhZgUDwX2xEU84vzo9ms51x3nLg3fEA72FRewUyvnlqyHbTmM0tMYdJv 18IZjj+yvZ03hCmLoWSs+hU+LkOdxEdNgTcZWC9nkoReo6eM5dTbtCnNBOAdfrA== X-Gm-Gg: ASbGncvKovGrxDzOMQ+j+o2KQmaq6XnQQJQtCQM9gLo/GJCxI8sj5BrgQFYbCyoGnIp qS/bwfjtFYSgPvE4drFinvnW36vkUfEaIq8NwXgQA8WUKa13E8n42nlEuf83hioqP5QyeU4bfD9 H/FlLwvv5AF1ecdRsX8e8t6ILkIGmV5Zt8MxFJjDgruUwSdoWS5ElEZ8v9yJVACIIkh0ILYLBGe 8CHdvbv3IWWwf/rw4/TziIPdw6PWoZ7lLqkAwND/Pf5gWl1n+CHlY/HZNYGufau0/piikUIqn52 k66dIHZtGHAjrA1wRdtAHlljM/es6y5Z X-Received: by 2002:a05:6214:31a0:b0:6d8:f7cf:a12 with SMTP id 6a1803df08f44-6df9b2ff012mr6628136d6.45.1736282418864; Tue, 07 Jan 2025 12:40:18 -0800 (PST) X-Google-Smtp-Source: AGHT+IH3x2JnYKqYDGZceKkbdYysg3OVrQ5XZc6PkLXZvto1IqyPEH4R4CSwLbtkmwcRm2B/Q8ATbw== X-Received: by 2002:a05:6214:31a0:b0:6d8:f7cf:a12 with SMTP id 6a1803df08f44-6df9b2ff012mr6627846d6.45.1736282418604; Tue, 07 Jan 2025 12:40:18 -0800 (PST) Received: from x1n.redhat.com (pool-99-254-114-190.cpe.net.cable.rogers.com. [99.254.114.190]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd181373f6sm184478306d6.62.2025.01.07.12.40.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jan 2025 12:40:17 -0800 (PST) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Breno Leitao , Rik van Riel , Muchun Song , Naoya Horiguchi , Roman Gushchin , Ackerley Tng , Andrew Morton , peterx@redhat.com, Oscar Salvador Subject: [PATCH v2 7/7] mm/hugetlb: Unify restore reserve accounting for new allocations Date: Tue, 7 Jan 2025 15:40:02 -0500 Message-ID: <20250107204002.2683356-8-peterx@redhat.com> X-Mailer: git-send-email 2.47.0 In-Reply-To: <20250107204002.2683356-1-peterx@redhat.com> References: <20250107204002.2683356-1-peterx@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Either hugetlb pages dequeued from hstate, or newly allocated from buddy, would require restore-reserve accounting to be managed properly. Merge the two paths on it. Add a small comment to make it slightly nicer. Signed-off-by: Peter Xu --- mm/hugetlb.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 922d57e2413a..3b27840de36f 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1361,11 +1361,6 @@ static struct folio *dequeue_hugetlb_folio_vma(struc= t hstate *h, folio =3D dequeue_hugetlb_folio_nodemask(h, gfp_mask, nid, nodemask); =20 - if (folio && !gbl_chg) { - folio_set_hugetlb_restore_reserve(folio); - h->resv_huge_pages--; - } - mpol_cond_put(mpol); return folio; =20 @@ -3052,15 +3047,20 @@ struct folio *alloc_hugetlb_folio(struct vm_area_st= ruct *vma, if (!folio) goto out_uncharge_cgroup; spin_lock_irq(&hugetlb_lock); - if (!gbl_chg) { - folio_set_hugetlb_restore_reserve(folio); - h->resv_huge_pages--; - } list_add(&folio->lru, &h->hugepage_activelist); folio_ref_unfreeze(folio, 1); /* Fall through */ } =20 + /* + * Either dequeued or buddy-allocated folio needs to add special + * mark to the folio when it consumes a global reservation. + */ + if (!gbl_chg) { + folio_set_hugetlb_restore_reserve(folio); + h->resv_huge_pages--; + } + hugetlb_cgroup_commit_charge(idx, pages_per_huge_page(h), h_cg, folio); /* If allocation is not consuming a reservation, also store the * hugetlb_cgroup pointer on the page. --=20 2.47.0