From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7E59531F9B4 for ; Wed, 29 Jul 2026 02:01:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785290468; cv=none; b=RtGC+NNeNU660/zqLXbjV16hN0UEWPPqwHC7iHi6dnGlwDdvPioyJ0KmT+HMwRE1pJbVz7blfC8S13dKsKAsoubxeRsH/+fLrenSoTLGM6BKSuaIda7b5MSX2qWVvPVSrqGwMPL/+M+lEwUEXmxoKqDVGe5arUZ8A1Z+1MkUZhE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785290468; c=relaxed/simple; bh=eNPkjAeTFFEup4r8l+z42pBVWDiPic/9ozk1yJMmQE4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=j1+36eCl5h1zsUvuI0K5d/0PE7NG3vqbetBgoCQnVGTwY423V0lhrau5iBF2RTmc802iYDVaqyqDpD5OaBAlCz5geXn2LV0bPlOAxuw3I7jwTSx1hSC9k7BqQyJhiLI+290ChmufI0rzeC/FbP7u9U04JZCIWJI3koEvQK7hetg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=X6JMWYb0; arc=none smtp.client-ip=209.85.222.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="X6JMWYb0" Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-92e5c9211d2so44593485a.1 for ; Tue, 28 Jul 2026 19:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1785290465; x=1785895265; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Og/k718MfI34g9XwAhuwuQilIeorUnfQgYxJimga5lA=; b=X6JMWYb0r+nC9FPtQayq5dR+Uvl1FBlD0nPPsx8j0jXRwZd7QoFsm9y6s8utprr3Ml 5Vfa4mjZcAMuWelPZdRqPzJ8cScJ9Qg0t+nUXarXXKb3HJYnch0cB0OMp5iKx7QkONwJ qGCoa7WHEmsaKZDa9w+HIsGSLeKeAB2893/glqpwiDxzHZpNZW9IbZ5lupc0aSeEsGsp 1RRqeFlJ2f+xFxbBhbEdIfIZH2uKRMQNiEJucNsb94qlB4/2GdzMZZ55To7F3uIuBJtM 3prz82ohGEHoexFN4u6mbRVNggO7hHjCjd+f40Kb95szwxlPPKfAsBAMiZURSNGIDkZq Gzmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785290465; x=1785895265; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Og/k718MfI34g9XwAhuwuQilIeorUnfQgYxJimga5lA=; b=f1O5EN52raRO7L7hHVbggG4OKLb4A/ExUrVtoEp+ZvTJFnXEFuKnd5BcdhK97uu3Tf ywKNGx+JrO//kAOE99t0H0G0FmkT3F6qmTr6zCXlftbnKAfCYmYIpY2Umv4Qb8PfiC5a VAqULExeOTa5miBh57EdiZMfCHgqb5/TYom5KLU5znBy0WJQqMcTlOgsINao6+Ve796v UC23hKTDVfSdPGh5kC5FV7/RE3qJ1TT5TtCDMNksd8XncH9mm/rJo7ntBcQ9lAEfEcj1 I1GEi0NrRtk7tk/J87T2P9p2y0xXTxLLLkVaHtBKJHw0HacSIap49zA3iDYI/pW/o+Rt Wc9w== X-Forwarded-Encrypted: i=1; AHgh+RoaSlpQnsdrkCXJeXoJh2mYJ6/3Zc1HvCDYmehE/L5erX7hD6ZnSCiAdC42wvQT4oOTv7DC/ZKmTB8uEjg=@vger.kernel.org X-Gm-Message-State: AOJu0Yyjn8tv4tx3OkXuhkNZvXXXwtu8jFgmsRVpuaHqKbN0izlNyLuY USyLwDnLBZQEAG2xfg3sbmYbUt6e+eXD2JRq5XRKuWiGUhPgR1DQflRTuPddzYZD54s= X-Gm-Gg: AR+sD12kAlQ6abEG1Ig6QvmnxwK4/hFFmFScQQthdiHQmllQxi5Paj/fNnUsT/dBoi3 /D9IT7DVwiOuUX/9YgBZI9jX6VgM2BUjushGBTUjP5D1pnQlIEgt3SFGOPZ8MR4JUESRidIfG3U AuiBbpZsODiVjKuIVK7GqaIb2N8/2txNPu5rX8zOZLXpg2XfpHXRbvr+/xmFkOtr0FM6U3p8a7u SAtr6HqzyI+QqK9TEJa4ea4VtFHTi4rVTcunxH/IWFVxkf0ZJSinjf2PEv4+jRZxi8ANU5b0sor xQ+cjNOwKNV6MZG75WnMbCOXY9UgtMLQ9MWdDSaZdzlU+OjrVw/FlFnfEVwO+22BqHwExyTm8Pr h+lyZk3+tcVGIIwkGzmfBK5pk2/rHkPoalqkfV4UHBzwAF1UHYDdidIHdG2hezlil3a8tbwGIzY vR/FI8dLrN4C3G7ojCjL3CCV9IkD9fUOih8hc6pHluFSuMmRmz3jtBtMScWDsDNsTQPlkhBlbA/ 8gwQbiCx9t5DrEcBj9IK8WC7SDn301dxQBK/rMARs96pev+1VHE+7Nm X-Received: by 2002:a05:620a:170d:b0:92e:c118:18b2 with SMTP id af79cd13be357-933027293f1mr509740785a.81.1785290465281; Tue, 28 Jul 2026 19:01:05 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-173-79-60-52.washdc.fios.verizon.net. [173.79.60.52]) by smtp.gmail.com with ESMTPSA id af79cd13be357-933d3221ac2sm67571885a.3.2026.07.28.19.01.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jul 2026 19:01:04 -0700 (PDT) Date: Tue, 28 Jul 2026 22:01:01 -0400 From: Gregory Price To: SJ Park Cc: linux-mm@kvack.org, damon@lists.linux.dev, linux-kernel@vger.kernel.org, kernel-team@meta.com, akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, ziy@nvidia.com, baolin.wang@linux.alibaba.com, liam@infradead.org, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, usama.arif@linux.dev, vbabka@kernel.org, jannh@google.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, ying.huang@linux.alibaba.com, apopple@nvidia.com Subject: Re: [PATCH 1/4] mm/damon: defensively skip zone device folios in damon_get_folio() Message-ID: References: <20260728194714.3713735-2-gourry@gourry.net> <20260729005036.98063-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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260729005036.98063-1-sj@kernel.org> On Tue, Jul 28, 2026 at 05:50:36PM -0700, SJ Park wrote: > Hi Gregory, > > > On Tue, 28 Jul 2026 15:47:11 -0400 Gregory Price wrote: > > > All DAMON physical- and virtual-address operations obtain their folios > > through damon_get_folio(). That helper already excludes ZONE_DEVICE > > memory implicitly via pfn_to_online_page() and folio_test_lru(), but > > this is inconsistent with other callers in mm/ which test explicitly. > > > > Add an explicit folio_is_zone_device() rejection in damon_get_folio() > > so the guarantee lives in one place and covers every caller uniformly, > > consistent with other mm walkers that reject zone device folios. > > Thank you for checking this and sharing this nice patch! > > However, I'm not very sure adding a call that not really required for only > making it looks consistent with others is the right choice. I'm especially > concerned if this will confuse future readers including myself. > > If this is a hardening purpose, we have CONFIG_DAMON_DEBUG_SANITY for the > purpose. What about using it with a good comment explaining why we doing that? > It's actually two fold: 1) make zone_device more consistently handled across mm/ 2) make these checks possible to abstract out later In the private node work - every location that we'd need to filter folios based on private node membership is a zone_device check. Where zone device checks are missing (like here) there's some other implicit reason (specific to zone device) that allows it to be avoided. I pointed out in the sashiko feedback that DAMON depends on a check for folio->pgmap in the hotplug code. This is all quite fragile, and we can see that at least one patch in this series fixes an actual bug. It seemed warranted to go audit every service and add the zone_device checks to make it clear there's a zone device interaction - even if presently unreachable - should some silent, implicit filter change. The goal is to come back around and replace these with something like: bool folio_allows_mm_op(struct folio *folio, enum node_states feature) { if (folio_is_zone_device(folio) || !node_state(folio_nid(folio), feature)); } - if (folio_is_zone_device(folio)) + if (folio_allows_mm_op(folio, N_MEMORY_DAMON)) If we ever get to folios having memdesc flags beyond page flags, this also gives us a single mm-wide location for these kinds of checks in the future. ~Gregory