From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-m15591.qiye.163.com (mail-m15591.qiye.163.com [101.71.155.91]) (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 54592234973 for ; Wed, 6 May 2026 04:31:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=101.71.155.91 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778041918; cv=none; b=QvDHMv+DEsFPwUJnwqB90kp33VXCkYM8V7SSiBDZfIwRqlmCx34w7wWmzpV8bsogqMc4CA8TnsXEx7VJj7G7aS5K0Xe2YKBqbBiy579l6M/fuKOWikH5GZMqnRyctLaqoXIhfxGPADxRpMIPN1TiIMMJpC3odMwXHDvANAAo0M4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778041918; c=relaxed/simple; bh=5ZsIT3QQcFkAHvL4fFQ1qz+xR7uDnyON93fnSmmww/A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rin7xd3LYaY05p/JWJEFAuQCIfhrBQo+FXiCJktvIabUMuy6EDxKBMSVOcUEzXlPdcCogTx3M4FykUsUxkrEHxrSQhKgOk3jTTq4OLZFSuULIvlJRVW4B5yzyVh9aYUIncUL2spdw49xeKxQOybIAuI71o71TbUIpkhF31M9bks= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=easystack.cn; spf=pass smtp.mailfrom=easystack.cn; arc=none smtp.client-ip=101.71.155.91 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=easystack.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=easystack.cn Received: from [192.168.0.59] (unknown [218.94.118.90]) by smtp.qiye.163.com (Hmail) with ESMTP id 19bdc5e48; Wed, 6 May 2026 11:16:05 +0800 (GMT+08:00) Message-ID: <0f0d9a2d-47a9-4150-ac97-83a92ce8c048@easystack.cn> Date: Wed, 6 May 2026 11:16:04 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 0/3] mm/page_owner: add filter infrastructure for print_mode and NUMA filtering To: Andrew Morton Cc: vbabka@kernel.org, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260430163247.13628-1-zhen.ni@easystack.cn> <20260430112245.be3189f09bd6a71970a74746@linux-foundation.org> From: "zhen.ni" In-Reply-To: <20260430112245.be3189f09bd6a71970a74746@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Tid: 0a9dfb4919cd0229kunm77ae86b41592a8 X-HM-MType: 1 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFJQjdXWRgWCB1ZQUpXWS1ZQUlXWQ8JGhUIEh9ZQVkZSUJCVhkdSRhOHk1MHUwdGlYVFA kWGhdVGRETFhoSFyQUDg9ZV1kYEgtZQVlJSkNVQk9VSkpDVUJLWVdZFhoPEhUdFFlBWU9LSFVKS0 lPT09IVUpLS1VKQktLWQY+ 在 2026/5/1 02:22, Andrew Morton 写道: > On Fri, 1 May 2026 00:32:44 +0800 Zhen Ni wrote: > >> This patch series introduces filtering capabilities to the page_owner >> feature to address storage and performance challenges in production >> environments. > > AI review asks a couple of reasonable-sounding questions: > https://sashiko.dev/#/patchset/20260430163247.13628-1-zhen.ni@easystack.cn > > Will this cause KCSAN splats? While the practical impact is minimal (debugfs interface, infrequent writes, torn reads only cause temporary debug output inconsistency), we should properly handle this to avoid KCSAN warnings. I'm wondering if using the __data_racy qualifier would be appropriate here? Something like: struct page_owner_filter { ... nodemask_t __data_racy nid_mask; }; Is it necessary to evaluate nodes_empty(mask) inside this loop? I'll fix this by moving the check outside the loop. Best regards, Zhen