From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 206EAC7EE30 for ; Sun, 29 Jun 2025 20:49:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CFBB6B0092; Sun, 29 Jun 2025 16:49:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8807A6B0093; Sun, 29 Jun 2025 16:49:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 795ED6B0095; Sun, 29 Jun 2025 16:49:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 677446B0092 for ; Sun, 29 Jun 2025 16:49:20 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 047BD14024E for ; Sun, 29 Jun 2025 20:49:19 +0000 (UTC) X-FDA: 83609628480.30.344D8E7 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf20.hostedemail.com (Postfix) with ESMTP id 655551C0008 for ; Sun, 29 Jun 2025 20:49:18 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bcizsm76; spf=pass (imf20.hostedemail.com: domain of sj@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751230158; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=8sKR8nvsyTlbbNDfaveRItRqWlV8uC9EmcVEmINh+18=; b=vW55YpPFcKIgUSuzZNoYpVBElMhwRtX2SUOlnvUotGKDRvIAcjwpFZ3l/FSWJ2SPoiiBAk E1UYpX7sjRehuXcGQDPUO+bmPiuhr1NSuhVj1BYNa+BXw3F0/wLReobtZLTHYazwkHFGdR xibQxciWVHGskGpebDTK5x7RKMxQ5fY= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=bcizsm76; spf=pass (imf20.hostedemail.com: domain of sj@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751230158; a=rsa-sha256; cv=none; b=H9dhloRAC0W62oJrD/Pymi7btfYvWR0yR/FjeunYuIUWy7SVL/ZnF09dziVuc4/Ojng7eb eIVXzXsWmjPKvOyiLtJVRoj0LWTTCtYObzwV+XX3Xi0VasqOvp5Voxd13c83IICCVhIcaU WQ6EI8gtsVAEKo1M7fc6smiUnufzSLk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 42CF845156; Sun, 29 Jun 2025 20:49:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01386C4CEEB; Sun, 29 Jun 2025 20:49:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751230157; bh=XUP8lKIddKhAygDomeQIMUIjsYMoEKXPeWmno3HafKE=; h=From:To:Cc:Subject:Date:From; b=bcizsm76+XFW+2WXfnx4wgPXGwPvmvZRg0HKUj/aIbI6oh2PYfuRoZiWdBR0temqu Ll51Lw7VzehYKidIL19nhQVMwY0Py66m+6TQ0HpdXOnOiUegArrdTn/Z2DY5UVHe7Q wYjCn0eKQWvy9uM/pyukXLANGuTvwZuMKDlP57o1GE5T0s/5cHGfQ3qAi+MKnsszLS 5AlKfBHriydEIsRnH5czP52qqg1VBMxzdE9sQ7m2NFZg9yK2fKiGcUFhAL1nfE4F84 iZHzPK37hob/Pjnn6EUz6rSYcASW5S7ymn+gNHaLz3geOt6YFlUmdj0eXTGX9Wy6mI ZWu6jznJ8kYeg== From: SeongJae Park To: Andrew Morton Cc: SeongJae Park , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org, #@kvack.org, 6.14.x@kvack.org Subject: [PATCH] mm/damon/core: handle damon_call_control as normal under kdmond deactivation Date: Sun, 29 Jun 2025 13:49:14 -0700 Message-Id: <20250629204914.54114-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: 6wpkfywoqj7q49rfsdso5g761rftquyj X-Rspamd-Queue-Id: 655551C0008 X-Rspamd-Server: rspam11 X-Rspam-User: X-HE-Tag: 1751230158-879458 X-HE-Meta: U2FsdGVkX1/iQ8ig7/t16bhT7LufkUxUzuhgj5DeSziHQ3owHDDxCPZj7UaKeX+tLrH8LQqf9WbJTi2Iiiwmmx6fFE7JrmfcvgG7mBpT7t49Ka9rmPdNGFO9H907moDk/gJKYVuW9UICfTIWBS2JQCYiZK7U7ZzGG9lvl6cDkOuSmSeNftJEMfgcu59k09JEffzwaUI2B79lMWzgd8EwKzXqGvSNHJe76V5oLy4vxIwBrlGyxmAAJWKTYwV2TdLdbtlGx2NZaMe/FPqoq342Cc1A6iwjNG7FbX5Oo2Y+qWM/22+0N+qNuRS+9IB6z+bFjvG9zLExFN0EE5R1R5mOe/7bAEW3xdH6jmXcIayKQh9eOe0kGD6wJJTDk7gGBZYwrm5lvfRx9xSekY5PT2GIMoJc1/NWrWnNC/cTAg1OKOiNPShuVgPF1OoJL6YiOVhxvW7aMh63y5MjRvC1Lmqqskfk7tmI3q4/5KAwn2sbexDE1Oe0PGJg1z0NhAzx2DBX6UdCOQmL2h6wiR/9bONR6raNzKv9Wz81hF8XBC9jYzCBrxb7j9ghw/GYd1hRZZsIrcLezwiicz/DNMMhx2x+5RJYu/hAoe0Y7rGr82X3OMrCBr0DRvP1n56HYH2UbVNFrkwfAMO+YhRYmWJxAnamrxq2wZT7l+4ueTlN4nlMucxwSUMqJDL9EfdtLVEPLAcUaEgTV/ZoAWCU6bbdfrG/0MTq/9OC87r/yoLDDLWlwA4KBzxw7WjQ75yimDkbZ304kesAg/9uRGzbjLYn3x5+P1f5ZYqYwRHYEr0e1Ps4ciAEJh5Hajkms5V8/q+GzFqCkyBiIZK8N1s4CDEsscStEO6SbBQTq7IVgMfFkNuB/JI+XWN5nElL8kaLUCNSC5w3Le2GorrMTBME1yzjlkxNH5vlIwMnSgDEs5spYq9sz4J069wNV7LK7bn5SY+0GeGAhXEkrLSem+GlfCbCePg GcXIjnNX cki8FOev661qzjd5FugAqUtknTPw8ocoGfhsnLIvJj5jnEc+4eyQV0ajxf+JxAqwri0/C8fXT9zYhdZlAEGn+zLBIAiwefzkP+6EFVTBssuRHACFJ/Z44RsuSxy2Wg/cOJ6KstIYWIV6gmX/bRHdnel8z5POR1p1cNlxTeFvk79rXF3WIZU6kIz7VWyz5szitz1nOhCa1CuQJ28KmNQXaJo8Dpf5s2/I6s/nh5kcbUONTPbfU0+R+EdwpBUwRmUUx+1RBVve2QqG+35CP6B3kaS8tAf921CXw+iWYnqTEEP8yBuv5tyTPe99Wqw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: DAMON sysfs interface internally uses damon_call() to update DAMON parameters as users requested, online. However, DAMON core cancels any damon_call() requests when it is deactivated by DAMOS watermarks. As a result, users cannot change DAMON parameters online while DAMON is deactivated. Note that users can turn DAMON off and on with different watermarks to work around. Since deactivated DAMON is nearly same to stopped DAMON, the work around should have no big problem. Anyway, a bug is a bug. There is no real good reason to cancel the damon_call() request under DAMOS deactivation. Fix it by simply handling the request as normal, rather than cancelling under the situation. Fixes: 42b7491af14c ("mm/damon/core: introduce damon_call()") Cc: stable@vger.kernel.org # 6.14.x Signed-off-by: SeongJae Park --- mm/damon/core.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index b217e0120e09..bc2e58c1222d 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -2355,9 +2355,8 @@ static void kdamond_usleep(unsigned long usecs) * * If there is a &struct damon_call_control request that registered via * &damon_call() on @ctx, do or cancel the invocation of the function depending - * on @cancel. @cancel is set when the kdamond is deactivated by DAMOS - * watermarks, or the kdamond is already out of the main loop and therefore - * will be terminated. + * on @cancel. @cancel is set when the kdamond is already out of the main loop + * and therefore will be terminated. */ static void kdamond_call(struct damon_ctx *ctx, bool cancel) { @@ -2405,7 +2404,7 @@ static int kdamond_wait_activation(struct damon_ctx *ctx) if (ctx->callback.after_wmarks_check && ctx->callback.after_wmarks_check(ctx)) break; - kdamond_call(ctx, true); + kdamond_call(ctx, false); damos_walk_cancel(ctx); } return -EBUSY; base-commit: 8f6082b6e60e05f9bcd5c39b19ede995a8975283 -- 2.39.5