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 465BE563FBB; Wed, 9 Sep 2026 14:41:13 +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=1788964874; cv=none; b=EHxshzghuhKQn4KKaZDOqaFdJBXlqZ909GNaQE/20NL4gaCY7LvnhU1LdrHZS+fJH+mJtFis4Gkrudc9tgcqNarkPhLePUm7fEu/3jq072RqU7Q+qeOAitHK9u4sXIjTTpG2/3u6oeyBW5knvgbxxBUAZhqGd2UeBtM2KNl9+Bo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788964874; c=relaxed/simple; bh=d2NuVHXWRXl4jX2LBXuZcxijaIqqazT7dPJyfimUUaA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=a8sn97m0HiTKjJ/lHslX6ATREJbChCpBAY2lxVjwfKkuqKCKjiB/QLwDQxSqIg1/7lL8L2AKLZrbaUMuRYIz/C49NTdkiPcbEZPgTh8Rco6RfnOvBxJSrhBM+Ln7yMDVDgV38ze7dOAFkq2TaHPZReoKoO+BralOdaortC/Foy4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=I1dOUnpR; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="I1dOUnpR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6983B1F00A3A; Wed, 9 Sep 2026 14:41:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1788964873; bh=9F4T0cwnNk5xWpDaF2Az1CFpx6cnr/hPAcWj//MkMpE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=I1dOUnpRiktEYIkISl0AJW2VPRNT53pjkTTyrfiHgms6oVtXlBYtIVcyyBk8bEOGD dDdqGgMzYcrbQ8KMBWGjNggkh/uKxA2Ae3YXSPl9B6Iu2NpMNftH0Q9+V4ewzBAX4n xZley7SRGGZjMcGRVLTDFTX7d/Q6s5uOSa00A7OQ= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, SJ Park , Brendan Higgins , Andrew Morton Subject: [PATCH 6.18 574/583] mm/damon/core: initialize damos->last_applied Date: Wed, 9 Sep 2026 15:44:19 +0200 Message-ID: <20260909134257.708433306@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260909134237.773280130@linuxfoundation.org> References: <20260909134237.773280130@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: SJ Park commit af5f76aeb9c9aa9c77d5e1d94e0ee4618c805239 upstream. Patch series "mm/damon: fix uninitialized DAMOS field and kunit exec expectation bugs". Fix a few Sashiko-found unurgent bugs. Patch 1 fixes use of uninitialized damos->last_applied field. Patches 2-7 fix DAMON kunit tests that do invalid memory access under test failures. The bugs are better to be fixed and eventually merged into stable@ kernel. That said, the fixes are arguably not urgent. Patch 1 only introduces negligible DAMOS efficiency degradation in occasional cases. Kunit fixes could introduce quite bad consequences but those are test code that affect only test run setups. This patch (of 7): Multiple DAMON regions could exist across a folio. If they fulfill the condition to apply a DAMOS scheme, the scheme could be applied multiple times to the folio. To avoid this, each DAMOS scheme stores the folio that the scheme was applied to last time in the damos->last_applied field and skips repeatedly applying the same scheme to the same folio. The field is being used without initialization, though. Hence, the mechanism could wrongly skip applying a scheme to a folio at the very first time of DAMOS run. The user impact is trivial. DAMON might unexpectedly skip applying DAMOS action for one folio for the first time per scheme. In the DAMON's best-effort world, this is never a real problem. No critical consequences such as kernel panic or memory corruption happen. It is a clear bug, though, and the fix is straightforward. Fix the issue by initializing the field in DAMOS scheme creation function, damon_new_scheme(). The issue was discovered [1] by Sashiko. Link: https://lore.kernel.org/20260718001442.87129-1-sj@kernel.org Link: https://lore.kernel.org/20260718001442.87129-2-sj@kernel.org Link: https://lore.kernel.org/20260714055436.120034-1-sj@kernel.org [1] Fixes: 94ba17adaba0 ("mm/damon: avoid applying DAMOS action to same entity multiple times") Signed-off-by: SJ Park Cc: Brendan Higgins Cc: # 6.15.x Signed-off-by: Andrew Morton Signed-off-by: SJ Park Signed-off-by: Greg Kroah-Hartman --- mm/damon/core.c | 1 + 1 file changed, 1 insertion(+) --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -412,6 +412,7 @@ struct damos *damon_new_scheme(struct da INIT_LIST_HEAD(&scheme->filters); INIT_LIST_HEAD(&scheme->ops_filters); scheme->stat = (struct damos_stat){}; + scheme->last_applied = NULL; INIT_LIST_HEAD(&scheme->list); scheme->quota = *(damos_quota_init(quota));