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 5EE76C19776 for ; Fri, 28 Feb 2025 04:48:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C5FB280004; Thu, 27 Feb 2025 23:48:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7774C280003; Thu, 27 Feb 2025 23:48:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 665A9280004; Thu, 27 Feb 2025 23:48:52 -0500 (EST) 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 48CD5280003 for ; Thu, 27 Feb 2025 23:48:52 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B0FBC822B1 for ; Fri, 28 Feb 2025 04:48:51 +0000 (UTC) X-FDA: 83168123262.23.2AC51B5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf25.hostedemail.com (Postfix) with ESMTP id 0E0A0A000C for ; Fri, 28 Feb 2025 04:48:49 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GyIe18NJ; spf=pass (imf25.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 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=1740718130; 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:in-reply-to:references:references:dkim-signature; bh=vvUvwFtcTJa5dOp6XEoMXQaElsA2W+hpyDIAop+l55c=; b=B+tYLDW38+OZQoZIJg+kA6ruzO3pyAJ/QRucGuJ72fVL3sNO9Qsie+yiKlXH6ZGbuz53+n 9V66xW737tVELIf6SVq6g07pl2GR3A/gi3iBQ6U2QBmVxpFRIKxfHZ7Z8yQ2Ev+54XoK+r d0sYHaM9tNsvDYBgNhdpfXyNdFRpxr0= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GyIe18NJ; spf=pass (imf25.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 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=1740718130; a=rsa-sha256; cv=none; b=N6WjNsbaqUDFAzR+EItzf/qvMjVhfpllprr6BZ7820tDoJG/7Gaj9OtbEUTLQkRjNm5MSP ItrhbedhJWIeijJdQiDBa2h+Um0jgbdOuZ3IVYsKmexnJsWewb6WOIFH9pXol09lbqk6Of 12R01q8FSifpZwNmSKqySz+ikVrL5YE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2C7E65C61D4; Fri, 28 Feb 2025 04:46:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92904C4CED6; Fri, 28 Feb 2025 04:48:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740718128; bh=owXeyU0H6ZW3/VpDdEje1Z6EvdsqqKiXBOUx5xhzvlE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GyIe18NJc6+txFIeuJWX2mynlTQH8hr01zGXWZxq3dTPU7PbaxZ51z15OMDtdQkoA 6vRfM6UCr7xpHVEerWkCH64kToVfSKe3pwaCu8/fBUFHlO4PjhOKH52zDD7AiEHYnA W89BsmojPYAhvhvyYzO9kNeC6mwtxXd6kCkRDsSDKB4KZ2PvBLvyXHAljwn1teBbGx H5NlOb6VH37VF5mpLetMC/eD5Uwomvuab9Fecv8DvIDVhkWi1dEkMtm2xh7gVEjeGe CMy2tm6o2T3h1fkQ+vxuH0cnLS/vGs832pxGqS9yZfR80p7z1vsL/5h5QgMbck9PxZ dGnK+0PC1knHQ== From: SeongJae Park To: SeongJae Park Cc: Andrew Morton , damon@lists.linux.dev, kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH v2 7/9] mm/damon/core: set damos_filter default allowance behavior based on installed filters Date: Thu, 27 Feb 2025 20:48:45 -0800 Message-Id: <20250228044845.37918-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250227055054.22813-1-sj@kernel.org> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: gu3bsusfhpxre73o4ho8o3qaqd5jzyt4 X-Rspamd-Queue-Id: 0E0A0A000C X-Rspamd-Server: rspam07 X-HE-Tag: 1740718129-916905 X-HE-Meta: U2FsdGVkX19ML8iMdrNDnLcl8oA7EBSfm+eqfsZahez3aBf89wL1zE/2wdLSfwEYpTs5ksMBx70mkEW1ZpjmApSMElyLiXI75n2a30IcyANV2JGFjs4+gfeeh/bDht+SBDXLEfGmKlvOmmYWA2Wd79E9oDQ2ee1XA8X9jT26sA6zfkTgraPlmaZfzWk/z9jxcB0KjEDeGZ+TxLgCHkklgAUpZFK3rO+0EPPwTntiVmopsLz+raOGXKybemLwO2N88eqzqNyOwubGEOt01u9qn3YJDClgdmze3F1fljgMCuKr0jmgLnTc/VjBjJYCwnYkgEDdTCNRjw14w4PJlkdj1I1NJ648Ma1/8GSvqvIO1byxONuAndgLeCCPDZUr+zLbTdRBHcq+4ivmBSGMLVCuCSdCkLjk03BzFqzIXYF2+Uj9/cx7TX9DW2zdtcrlslW6Ms6/IoNiKt6xsFhDuDicd987tO7dgdx2ofSgnh6kFBaVlsKaLzG2yeIdZsFjZBy+nNvlog0qJOb6TPq5nlY9PumD+H2J1QE5dbH5XicuK+ywD5jNQ3s4Ov+2hLbUagEuvZPxaIxXPUzB3qbU8HxFtpVkbJdUrf+SRT6uHUCxkktw+dXo9bAxeUdGhI3Jh3Z7NCL7jW+HXIS49z7URikP/C8jxXEyzJ1O6ZDHom9Nj3KzcDiDtcGMw24VypH2qgILm5IQSOdlzDotcjNVXfTLoPthQjUkFylcpNzatjj0N4deNwuv+1ALnODaEk9qIO9Bs9dq7wQMY5luD1ZGQ748b+jUdIKfezV9DJqzOkk0OnTgYOYlnDPqrzQQSlp6kLz9rGcgdnSog2yTVVefzbWhEZXc+NbOzXHfKVF6guoQFwCHlhX9PYRf5SyKwoCBnVZTVbgeq7t/qECdI48sE2PLNnOEpBKPAa8ztLdVaOt5fz0S70qpkhhYtXJv3dmeWj1FGx9+9Y/Df/lrOdc7ZaX fgsoThox BEuABWvSA4+26MipTUYJewefRWKUlObAJYB8vd5YNDFyQDVD5UIs8oWZlnQ9LTbqZ93lRRTF6crc5DAOOpkqkV9w9sY60DwABhfmz5YcDQZQGAzlwJYHVWCTf9iCDxI7lqvTwSkuzU2Wm6mtVDzP77+T1/bZQNXK/2om0snSCEfPjw+29Z6u/GfIWt5s4k+xauwiXiLH+9SvC1YkBxbMcTV7jwSRW1R4MhjS4uGnGrhGaQZOjOLQThfvSQmOa1OEIYrRu01ERRZNz7pyYYBWgwAjE0Q== 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: On Wed, 26 Feb 2025 21:50:54 -0800 SeongJae Park wrote: > On Wed, 26 Feb 2025 17:57:52 -0800 SeongJae Park wrote: > > > Decide whether to allow or reject by default on core and opertions layer > > handled filters evaluation stages. It is decided as the opposite of the > > last installed filter's behavior. If there is no filter at all, allow > > by default. If there is any operations layer handled filters, core > > layer's filtering stage sets allowing as the default behavior regardless > > of the last filter of core layer-handling ones, since the last filter of > > core layer handled filters in the case is not really the last filter of > > the entire filtering stage. > > This is not sufficient enough. Even with this change, core-handled allow > filters after core-handled reject filters are still meaningless. > > If a region is matched to a core layer handled filter, the allow/reject > decision should be respected while ignoring all remaining filters, regardless > of on what layer those are handled. It works in the way for reect filters, > since core layer-rejected regions are not passed to the ops layer at all. In > case of allow filter, however, the region is passed to ops layer without the > information about whether it has passed to the ops layer because it was > allowed, or just not matched to any filter. Hence, all ops filters can be > applied to the region. > > We can implement this missing part by storing the core layer filtering stage > decision somewhere and let ops filter filtering stage repsect it. Changes like > attached diff at the end of this mail may work. I will add such changes to > next version of this patch series. I now realize this is not a missing part of this improvement patch series, but a sole fix for the allow filter behavior. The current behavior is not matching with the documented one, and this change will fix it. I will post a patch for this fix separately from this patch series. Thanks, SJ [...]