From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 E7F303A963C for ; Mon, 20 Jul 2026 05:54:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784526891; cv=none; b=qYC+vgRXVHkrkQt0fgolJgYChz5QbtGkBg/ftoEU1IfuvSBtFGVEQx5Ur4bYynNFMpvLEfw8FsYdEroPW4bSkm3xmKl40YUw91A1IH4/gcYuW+HULOyyWWmcmIIKYrpBBKcZlSroszGZv4DayPKcxqR1mouR87S1Fw50oHTk6E0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784526891; c=relaxed/simple; bh=XKQMqwVaa9fTs1Yw7iw2I4n7rZFhh71LAHsfug//nPE=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=A/xoWSTyjldgMXcSCPTQaPrAIPiQl0EswTzbzqPvxQEnOQNyeiP+LkQrF1+qxBWy7Y7XHOZKqXu7iJ4eHdMct4GNqRklBnxVt+0hPU6GjZIj4TJLYmk4DbEVxb56mMQCxjZ4gJ2hJy0A0rGBDF2LWeQCsshzmM6XqqQ/Txlx798= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=pov8w++x; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="pov8w++x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C32B1F000E9; Mon, 20 Jul 2026 05:54:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1784526879; bh=Vv5OoFLFLqo6apFeODcZIfFoAiaXPCnVVI60/8Q5tKM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=pov8w++xeZevdsFadUk7ss39KjD08TW37Hn9WpoETxN/x+3rJjbZPz0DVqqNTKq9B vVCHiepmPkpzuMCGf7Mhd9OXm+2d9h3r1k2uGQZvt74eE2fUrMNmUVI/QsA488KDJc vyt7+eko4EjwqMbfqAuJfNzLY5Iv3l8OA8QzE6IQ= Date: Sun, 19 Jul 2026 22:54:38 -0700 From: Andrew Morton To: Yichong Chen Cc: Muchun Song , Oscar Salvador , David Hildenbrand , Mike Kravetz , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] hugetlbfs: release subpool on fill_super failure Message-Id: <20260719225438.041287a56c87effe61796483@linux-foundation.org> In-Reply-To: <20260720021900.1376309-1-chenyichong@uniontech.com> References: <20260720021900.1376309-1-chenyichong@uniontech.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 20 Jul 2026 10:18:59 +0800 Yichong Chen wrote: > hugetlbfs_fill_super() allocates a hugepage subpool when size or > min_size mount options are specified. hugepage_new_subpool() may also > reserve huge pages for min_size. > > If root dentry creation fails after the subpool is created, the failure > path frees the subpool with kfree(). This bypasses > hugepage_put_subpool() and can leave min_size reservations charged. > > Use hugepage_put_subpool() on the failure path, matching the normal > put_super path. lgtm, thanks. This might have led AI review to find a pre-existing bug in mm/hugetlb.c:unlock_or_release_subpool(): https://sashiko.dev/#/patchset/20260720021900.1376309-1-chenyichong@uniontech.com > --- a/fs/hugetlbfs/inode.c > +++ b/fs/hugetlbfs/inode.c > @@ -1419,7 +1419,8 @@ hugetlbfs_fill_super(struct super_block *sb, struct fs_context *fc) > goto out_free; > return 0; > out_free: > - kfree(sbinfo->spool); > + if (sbinfo->spool) > + hugepage_put_subpool(sbinfo->spool); Both callers of hugepage_put_subpool do this NULL check. We could move that check into hugepage_put_subpool(). > kfree(sbinfo); > return -ENOMEM; > }