From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 3FC7437998F; Sun, 29 Mar 2026 15:36:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774798610; cv=none; b=a2ZvD66CtXsLLaB3FW1xFlgYswHYVOfV5O6TsKWy5+GxDkKeoFvAHO37ZDl5l3yA5HuCN4IXk4LTlSIZEXlZ+F0Lpftkki5n9/z3aFAfkRJ8ACSadkcSoPaAveZubY+J545GtAAUhMtPLkBrsAMBNLssNy0bXzLM6OifcXXJiJQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774798610; c=relaxed/simple; bh=wUEVhZoXsCyGZdr2zQUUKoIVCQrmq8kfzrwZor4bN08=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N6aiZ/493+GYR/w6V1vfr9MfiBY0kPWNTAc7ekjdgfYGgCZn8srkH9xmj20I61QQyseIVOmaK9ehdXgpqtbP/BKAmB3yG9oYIADJt7Q3/bnLBITaPhpn5TX6qaGb/vDDtDa4TStsvmYpqsaiTGjizfPQNedRaA8EQkpzhCrttq0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tqmzShbM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tqmzShbM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A735CC116C6; Sun, 29 Mar 2026 15:36:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774798609; bh=wUEVhZoXsCyGZdr2zQUUKoIVCQrmq8kfzrwZor4bN08=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tqmzShbM7Qn6aXcqe5+c6k2E0aMzkgs5OaKlOYuCnEhRM/jUzgAiaapNguG2bJzVJ LBxBoxQZLFWwyxHpC69+nTenFfwmxYsU9MOPRTZMH9Ev4YbIeWxa1IIg3tWWTSrOfY +GvHaKnvsNdHUCyxUCtm7bQRdkWoSihjfKq2thLNCFM+aq2bNLdRWrfeIqr89J78Ce TW//quEpKV/nGz2qrTGRcmTyROr0qhpBPdXc/jQJhQQXv5+zTQcfudzxIvJd6ce2GO j95JxJSq0RKVHEmG7j7o61GGTf39ea24fUBFhabhUile9ikDzHhuUNhZe/Fq3eIO47 JQ2jFIEowUJ2w== From: SeongJae Park To: SeongJae Park Cc: Andrew Morton , "# 6 . 16 . x" , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: (sashiko review) [PATCH 1/2] mm/damon/core: validate damos_quota_goal->nid for node_mem_{used,free}_bp Date: Sun, 29 Mar 2026 08:36:47 -0700 Message-ID: <20260329153648.47235-1-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260329153407.46989-1-sj@kernel.org> References: Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Sun, 29 Mar 2026 08:34:06 -0700 SeongJae Park wrote: > Forwarding Sashiko review for doing discussions via mails. > > # review url: https://sashiko.dev/#/patchset/20260329043902.46163-2-sj@kernel.org > # start of sashiko.dev inline review > commit 8c40c45c57722526c25cf1114b386d19a693fc2d > Author: SeongJae Park > > mm/damon/core: validate damos_quota_goal->nid for node_mem_{used,free}_bp > > This commit adds validation for the node ID in damos_quota_goal to prevent > out of bounds memory access when calling si_meminfo_node(). If an invalid > node ID is given, it defaults to returning 0% for used memory and 100% for > free memory. > > > diff --git a/mm/damon/core.c b/mm/damon/core.c > > --- a/mm/damon/core.c > > +++ b/mm/damon/core.c > > [ ... ] > > > static __kernel_ulong_t damos_get_node_mem_bp( > > struct damos_quota_goal *goal) > > { > > struct sysinfo i; > > __kernel_ulong_t numerator; > > > > + if (invalid_mem_node(goal->nid)) { > > + if (goal->metric == DAMOS_QUOTA_NODE_MEM_USED_BP) > > + return 0; > > + else /* DAMOS_QUOTA_NODE_MEM_FREE_BP */ > > + return 10000; > > + } > > + > > si_meminfo_node(&i, goal->nid); > > if (goal->metric == DAMOS_QUOTA_NODE_MEM_USED_BP) > > numerator = i.totalram - i.freeram; > > else /* DAMOS_QUOTA_NODE_MEM_FREE_BP */ > > numerator = i.freeram; > > return mult_frac(numerator, 10000, i.totalram); > > Does this code still risk a divide-by-zero kernel panic if a memory node > has zero managed pages? > > Even with the new invalid_mem_node() check ensuring node_state(nid, N_MEMORY) > is true, a memory node can have present physical pages but zero managed pages > if all its memory is reserved early in boot (for example, via memblock_reserve > for crash kernels or firmware). > > In this scenario, si_meminfo_node() sets i.totalram to 0. Since the > mult_frac() macro directly evaluates division and modulo, passing > i.totalram as 0 will cause a hardware divide-by-zero exception. > > Should there be an explicit check for i.totalram == 0 before calling > mult_frac() here and in other similar quota functions like > damos_get_node_memcg_used_bp()? As I mentioned to same previous comment, that's another bug that require another patch. I will work on it with a separate patch. Thanks, SJ [...]