From nobody Thu Apr 2 22:21:31 2026 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 4CB5E12E1E9; Thu, 26 Mar 2026 06:23:55 +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=1774506235; cv=none; b=hxW7LOUA/ham7UCheFEaq185P4GcAWlzWYoHHFaOuyLXXpqTbH6wJ3X5XRLJgNeSM/5rubl1rxlMEQkhHczS/eVri73gUEIHk48nHQ4ehnslrGLBq2JLbKmDjODZDOHO3QMDhsFUb/lAUeNiwXeFCkqoEl9CfyXT1uGUhUGFVBw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774506235; c=relaxed/simple; bh=RlvImuIw6Gj0I6frcAflxi6JM5UxJrr64Xql9+sFKw8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=R7AN8YGjnQiaKbN416RoKhj3XccnFCNNG+BzamsXN/1W5T19DvZx+tdxR1JQ/pSDOBMkMP5cZxCVEZbLD1S+LvyVleu5lg0NOkLDbfxXQlLJERl+1oFb3uc3hjMqAch4U89BHlGE+hYvtu9+A/vKa1M4v63+fbt2Mqm7r4yJGik= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BdE/wPLf; 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="BdE/wPLf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 063D8C2BCB1; Thu, 26 Mar 2026 06:23:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774506235; bh=RlvImuIw6Gj0I6frcAflxi6JM5UxJrr64Xql9+sFKw8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BdE/wPLfegTP3LfMONDrnSHdGGjqAP02qzisOsg/6SVv0il2Gz6Zo7psUV2GZR0La UYN1pyOIXYh+3pmFwvWs4Hv8fwX2/wUbJbLr0+gSajvOZmZzOEhVRhhCdVj2O4F3xc YiF0Sf5qct5ls494NsQVYa2Qr6i3X3ExK7hn1VTGkK3dNj7XyZ2729pT/1uqpdVpst 5+K8p+ATViUkRPdZX3bqi2gT85e7lPGApnlbLSxZ2snON6BVR+u7hxTwVrT5F/Rq4a ZZ8PgLYH409iRytJezh4+If98jlziGUqidgTXPbf70Kb2jrCvbXOuqYt/qX1wiXury Exr884/Z7/gBA== From: SeongJae Park To: Cc: SeongJae Park , Andrew Morton , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH 1/2] mm/damon/sysfs: dealloc repeat_call_control if damon_call() fails Date: Wed, 25 Mar 2026 23:23:45 -0700 Message-ID: <20260326062347.88569-2-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260326062347.88569-1-sj@kernel.org> References: <20260326062347.88569-1-sj@kernel.org> 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" damon_call() for repeat_call_control of DAMON_SYSFS could fail if somehow the kdamond is stopped before the damon_call(). It could happen, for example, when te damon context was made for monitroing of a virtual address processes, and the process is terminated immediately, before the damon_call() invocation. In the case, the dyanmically allocated repeat_call_control is not deallocated and leaked. Fix the leak by deallocating the repeat_call_control under the damon_call() failure. This issue is discovered by sashiko [1]. [1] https://lore.kernel.org/20260320020630.962-1-sj@kernel.org Signed-off-by: SeongJae Park --- mm/damon/sysfs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c index 6a44a2f3d8fc9..eefa959aa30ae 100644 --- a/mm/damon/sysfs.c +++ b/mm/damon/sysfs.c @@ -1670,7 +1670,8 @@ static int damon_sysfs_turn_damon_on(struct damon_sys= fs_kdamond *kdamond) repeat_call_control->data =3D kdamond; repeat_call_control->repeat =3D true; repeat_call_control->dealloc_on_cancel =3D true; - damon_call(ctx, repeat_call_control); + if (damon_call(ctx, repeat_call_control)) + kfree(repeat_call_control); return err; } =20 --=20 2.47.3 From nobody Thu Apr 2 22:21:31 2026 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 6EB7838E137; Thu, 26 Mar 2026 06:23:55 +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=1774506235; cv=none; b=GB6COs2CXrjA7bokk7BmOYLQ5qC0rmmtu/I5S1ZJuraQ+5vA5ksYqHutX1vR2NjAmD8uy0tC75u8sJFpYcRoakbfnrbUIyUfUSEUEOd5+POnJ/cAIiuiGB1t8s0Bo3mvIaS0GaDsRy0bio9gxnSQ1Qdn9/oc1glpfK+8fMJUnSc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774506235; c=relaxed/simple; bh=yZoBuHZtr5Af4B/Xpz7HSwkfDg5FS5Cb3q2CAhjdDrM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ME6b2gyfir19/Krg0ms67wkVmnqx6QXOwhg+6jSRKJpoDSW00IpHScYkK1X9MIIV1esQOt5hUSX7l5KK/6T+oWbZbEeens4o7rtc8jILro68SIFvhPXp/FDsvjABGQbUbmC4CZfYoj0b28I8J+AGTryZN1y+CxTbTCOVFFG3H5M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Mwy694kr; 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="Mwy694kr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AD2CC2BCB2; Thu, 26 Mar 2026 06:23:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774506235; bh=yZoBuHZtr5Af4B/Xpz7HSwkfDg5FS5Cb3q2CAhjdDrM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Mwy694kr/IucXYv3o4lC2wcGmle08x19rR8AKqu+ApQaw1MttHlYRk1xDjfyvAMw9 g2ZTIW+1aX1dNWinkhZL2TqZFnXF4AjEM72Emb9B6XENOWmz/RoEIMBR0cYzgZ8NYB P51XxGpZlLA24yflwmaciqrNigaY0I9oZqLfTyaTvAE9pnA3iAYxKCw41j1y90ex0A Mzc+Dun0MZ+33dOmRdR3UGFoAI/+8ZhqhMDP3YDdLcbPkWT909w+OALReQcZFsZl6g CU2V7a3Myj83O5kpFlhcUzCAHR4QKJFszZRj3nJ8DPGYb5nyTm2039NzMHA0B5GLVC tEJRvg6BSBrwQ== From: SeongJae Park To: Cc: SeongJae Park , "# 6 . 14 . x" , Andrew Morton , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH 2/2] mm/damon/core: fix damon_call() vs kdamond_fn() exit race deadlock Date: Wed, 25 Mar 2026 23:23:46 -0700 Message-ID: <20260326062347.88569-3-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260326062347.88569-1-sj@kernel.org> References: <20260326062347.88569-1-sj@kernel.org> 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 kdamond_fn() main loop is finished, the function cancels all remaining damon_call() requests and unset the damon_ctx->kdamond so that API callers can show the context is terminated. damon_call() adds the caller's request to the queue first. After that, it shows if the kdamond is of the damon_ctx is still running (damon_ctx->kdamond is set). Only if the kdamond is running, damon_call() starts waiting for the kdamond's handling of the newly added request. The damon_call() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damon_call() could race with damon_ctx->kdamond unset, and results in deadlocks. For example, let's suppose kdamond successfully finished the damon_call() requests cancelling. Right after that, damon_call() is called for the context. It registers the new request, and show the context is still running, because damon_ctx->kdamond unset is not yet done. Hence the damon_call() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so never handles the new request. As a result, the damon_call() caller threads infinitely waits. Fix this by introducing another damon_ctx field, namely call_controls_obsolete. It is protected by the damon_ctx->call_controls_lock, which protects damon_call() registration. Initialize (unset) it in kdamond_init_ctx() and set just before the cancelling of remaining damon_call() is executed. damon_call() reads the obsolete field under the lock and avoid adding a new request. After this change, only requests that guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no more needed. Remove it together. The issue is found by sashiko [1]. [1] https://lore.kernel.org/20260325141956.87144-1-sj@kernel.org Fixes: 42b7491af14c ("mm/damon/core: introduce damon_call()") Cc: # 6.14.x Signed-off-by: SeongJae Park --- include/linux/damon.h | 1 + mm/damon/core.c | 41 ++++++++++------------------------------- 2 files changed, 11 insertions(+), 31 deletions(-) diff --git a/include/linux/damon.h b/include/linux/damon.h index d9a3babbafc16..5129de70e7b70 100644 --- a/include/linux/damon.h +++ b/include/linux/damon.h @@ -818,6 +818,7 @@ struct damon_ctx { =20 /* lists of &struct damon_call_control */ struct list_head call_controls; + bool call_controls_obsolete; struct mutex call_controls_lock; =20 struct damos_walk_control *walk_control; diff --git a/mm/damon/core.c b/mm/damon/core.c index db6c67e52d2b8..a2b553e2c5a81 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -1573,35 +1573,6 @@ int damon_kdamond_pid(struct damon_ctx *ctx) return pid; } =20 -/* - * damon_call_handle_inactive_ctx() - handle DAMON call request that added= to - * an inactive context. - * @ctx: The inactive DAMON context. - * @control: Control variable of the call request. - * - * This function is called in a case that @control is added to @ctx but @c= tx is - * not running (inactive). See if @ctx handled @control or not, and clean= up - * @control if it was not handled. - * - * Returns 0 if @control was handled by @ctx, negative error code otherwis= e. - */ -static int damon_call_handle_inactive_ctx( - struct damon_ctx *ctx, struct damon_call_control *control) -{ - struct damon_call_control *c; - - mutex_lock(&ctx->call_controls_lock); - list_for_each_entry(c, &ctx->call_controls, list) { - if (c =3D=3D control) { - list_del(&control->list); - mutex_unlock(&ctx->call_controls_lock); - return -EINVAL; - } - } - mutex_unlock(&ctx->call_controls_lock); - return 0; -} - /** * damon_call() - Invoke a given function on DAMON worker thread (kdamond). * @ctx: DAMON context to call the function for. @@ -1629,10 +1600,12 @@ int damon_call(struct damon_ctx *ctx, struct damon_= call_control *control) INIT_LIST_HEAD(&control->list); =20 mutex_lock(&ctx->call_controls_lock); + if (ctx->call_controls_obsolete) { + mutex_unlock(&ctx->call_controls_lock); + return -ECANCELED; + } list_add_tail(&control->list, &ctx->call_controls); mutex_unlock(&ctx->call_controls_lock); - if (!damon_is_running(ctx)) - return damon_call_handle_inactive_ctx(ctx, control); if (control->repeat) return 0; wait_for_completion(&control->completion); @@ -2939,6 +2912,9 @@ static void kdamond_init_ctx(struct damon_ctx *ctx) damos_set_next_apply_sis(scheme, ctx); damos_set_filters_default_reject(scheme); } + mutex_lock(&ctx->call_controls_lock); + ctx->call_controls_obsolete =3D false; + mutex_unlock(&ctx->call_controls_lock); } =20 /* @@ -3062,6 +3038,9 @@ static int kdamond_fn(void *data) damon_destroy_targets(ctx); =20 kfree(ctx->regions_score_histogram); + mutex_lock(&ctx->call_controls_lock); + ctx->call_controls_obsolete =3D true; + mutex_unlock(&ctx->call_controls_lock); kdamond_call(ctx, true); damos_walk_cancel(ctx); =20 --=20 2.47.3