From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C922E2EBBA4 for ; Tue, 28 Apr 2026 11:41:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777376496; cv=none; b=dC+PEHgqHjIFgZon/L9M4kXA8426HrexzK04VX86yalX7cxAyTBR9PkXebPW6iBs07l978n7KphfAHygtghQhKpG2WxxupW4/XMUPw0wxH0+WhrCWeaeHZ6dQ4a7iozGvopK9RI9Vy3ByejnMFa26oNuqY5nCKM4R5zpZWCmEzs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777376496; c=relaxed/simple; bh=q9qdbuPABhIbyjFfUP2ehHRhmybFbzRhDDyJS+kB/3M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=liUxt2bqe77pxiM98jArT8wPqFekBlVFI+nlOX0ZcZ+2QA3QgYVH8lfVPgaqcOZxBrV0TjT195wr4yDXBVlzf0iaFJqV5ktaoCFSBZRDOiwxL+FHO8NLDLmjuisdatEI1pqGV2Ep6f/kK2s8feR5bKfeZUhNNtUFvwdQlBJfTb8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Y/As8y9S; arc=none smtp.client-ip=209.85.216.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Y/As8y9S" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-35fc0d7c310so7333235a91.1 for ; Tue, 28 Apr 2026 04:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777376494; x=1777981294; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=w4a/Yep8opuJO2xxXBuxlaVSwKZwZQ+8NCglGaJ0GMk=; b=Y/As8y9SWssDk6TuFAg8uKTBAzPLqbx6Zyo/JTgyh9zgjNt6gdPxlJDtC4UwW8U+Yg YvTyLl/OnzVNFhgZ80h7+98+2e9W3LrMc13ZWIWvzuFQ/QOYzMa58Kn1UiuRgLtDjjpC XS9KGY7xWIQHWhGSpe6/hzcFpFdB7WKE8q7qJdO7KZ8TK/3Ot6fhqiwaC1fGRClMA3cf lbrj7a5a6BPCecfZ7dmaGCPECrXV9uZflZB2UlDXNRhmciHAR7UBcTlX/JbOIJbCZnjq 1kSWQagT7pfIhNLdJtIn4FtX+gVDoOrfpIVHITlLk56BKyzzmnlzeHH7cfCWpGO4mNJu 1/fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777376494; x=1777981294; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=w4a/Yep8opuJO2xxXBuxlaVSwKZwZQ+8NCglGaJ0GMk=; b=GyksgoXrkvnwouxFgtmgsG9AOZbJFD/8RXvBDr4hoNRPJykPhtTss5IrYV1wUtKzYF uDT3IUzjtxfHhfSk3j/a4Lb1uDm3ls4maX8Ue7QIZbcGQ3BtINiDFBVIjj5oVvoglSv5 UIpPYuVEiQTN+wmRJfTNTJfwK9etGRwWr4BJC4UQT9cD3+lBF8X8hNLkzFz7fTCQeMRa x7U5U9/YbpFSc+69AeayYtPrTPxRF2Htel1JKD+vT33+J0FCK7KN8XJZlPRE7HAtozd/ WRsloizS/xv+AvE2oYFeujru0DfTHzOL1G6r+HozoA/tU9igi6DpXqMPD4H6F0U0zpFl mz2A== X-Forwarded-Encrypted: i=1; AFNElJ/+IS+qCJur+vKxo9F99eYmxgQKD9wWAIGB4ZU/sPYAKpGfXlZQz/EsbBZIPy77eKJ8ePiiABxCm0U7g1c=@vger.kernel.org X-Gm-Message-State: AOJu0Yxs3uaSkTT7qSpfjB5kRbqIb7p+UGUVWTrrpGerRS0y3kVl3qgx ajW+UuLpdOu11ebDOd6IW5ap39zJFoN2u7tVC2x1CdUTeCD01hqAyEhk X-Gm-Gg: AeBDieuOfEt994r/ph5/jS1HQg8cG6U2q7zlzo+FhzPUIBPTSk8nbBj6qzHql+NNS42 o2Jdp/hQ6vxMZaEH6XvxPcRcPm4LKs1nxRMrnpcgRSWjd8OGuOkLgYR9Xrehcw3T5wZJJ+RSjk/ dQmNVYUttkI49a1stVEzkCMFZH0gj2+aB+yxix9aVyHddkvrkR00/sSc+rK59EzIoFfv3+pE1q4 TXQrBYOIQdwD/y+xJfYDncE0k+tc3lGGD9sSIkH1QP+DkWAau5/9Hp3WUhxDKWXeWepmIaABgef peIxPHViKg2i64b6W2Z4dz9yT+gPRcV5uwLFurXkmlAq7swjshNsZ9pIFtpgCi/lD75CtRPALju cQjFqbhLgL4PjUWoR6i/fXr3GwdaAlZV5cJFv1194htY07xnPWbv0mjJbvzrr++9ChHepOwFcCa 2m7MSA63C6/Tflr5AAU7UMLp2bfzTHuDssmTB4gPZTh72RkPWAq/0hrFL3aUPcZawTWSU= X-Received: by 2002:a17:90a:da87:b0:35c:30a8:32a with SMTP id 98e67ed59e1d1-36491fbc576mr2900484a91.9.1777376494263; Tue, 28 Apr 2026 04:41:34 -0700 (PDT) Received: from KRHW1CJW23.bytedance.net ([203.208.189.10]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3648fd6f625sm3488762a91.0.2026.04.28.04.41.30 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 28 Apr 2026 04:41:33 -0700 (PDT) From: Zhao Li To: Oscar Salvador Cc: Zhao Li , Andrew Morton , Muchun Song , David Hildenbrand , Lance Yang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/hugetlb: fix subpool accounting after cgroup charge failure Date: Tue, 28 Apr 2026 19:41:27 +0800 Message-ID: <20260428114126.92091-2-enderaoelyther@gmail.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: References: <20260427145247.84157-2-enderaoelyther@gmail.com> <20260428030712.66256-2-enderaoelyther@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, Apr 28, 2026 at 11:08:04AM +0200, Oscar Salvador wrote: > I found that last sentence misleading, because we do not really > care about hugetlb cgroup charge/uncharge (besides that being of > the reasons we end up on error path) but rather the fact that we > fiddle with subpool->used_hpages and we need to undo that when we > rollback. Agreed - reframed in v3. The commit body now states the bug as the unwind missing the used_hpages rollback, without pinning it to the cgroup-charge case, and the subject is narrowed to "fix max-only subpool accounting on alloc_hugetlb_folio failure". > Well, that does not quite explain the problem I think, at least > not clear enough? [...] Fair - that explanation got tangled because v2's design itself was trying to compensate for racing min crossings. v3 sidesteps it entirely: the gbl_chg > 0 cleanup is now restricted to (max_hpages != -1, min_hpages == -1). In that configuration hugepage_subpool_put_pages()'s min-restoration branch is dead, so a direct used_hpages-- under spool->lock is the exact inverse of the speculative bump - no h->resv_huge_pages++ needed, no rsv_hpages publication, no racing-put reasoning. Mounts with min_hpages != -1 are left at v1 behaviour for now. That quadrant has an inherited race that also exists at hugetlb_reserve_pages()'s out_put_pages cleanup, so a coordinated fix belongs in a separate RFC rather than this stable backport. > I would split the comment in two parts and place them within the > block they belong, otherwise it sounds confusing. > > Subpools, reservations and hugetlb make a very head-spinning > situation, so let us make our life easier. Done - one short comment per branch placed inside the relevant code block in v3. Hopefully easier to follow now. v3: https://lore.kernel.org/linux-mm/20260428113037.88766-2-enderaoelyther@gmail.com/ Thanks for the review. -- Zhao Li