From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-m32115.qiye.163.com (mail-m32115.qiye.163.com [220.197.32.115]) (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 3D6533B9937 for ; Wed, 17 Jun 2026 09:08:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.32.115 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781687343; cv=none; b=hVJK1JQRtOX2LCbfyPJGA60PcG2uCP5Emcq5ti7RZQVHbe5He/OWm1Q0gTNhKIcWvSOIxkcTqNV4ma3isBVas25lx+SDyRIXpp9nX/KemDefFh7yeEPFdA4nTbKlp4L8hhmQizbS5jj1hQjWIKr3hdWYvfmrFEekkHNtgRsDx0U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781687343; c=relaxed/simple; bh=qTYh2TQJUVDbtA+kw9dW9Nr76B/n0DBAP8F7LQRpBXY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gKeJSjptFit5TP7w70u5Dc6Kle1ldIHus4LLTOqx3nBqf51rKRrO+AsPI+AC8S3vXtHWQ6iIrSG2l4Jmyy7HEy/cz/iWRchjS/MpKdcWFx6rfjzHczYupcx3r0jD/Drr1qGKVyAz4xHzGOEia9u8EcLNaGUKT018BfkSwMiwvj0= 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=220.197.32.115 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 1b8eaee8a; Wed, 17 Jun 2026 16:52:53 +0800 (GMT+08:00) Message-ID: <5ef656db-c6b6-4a2c-b6be-628e5214952f@easystack.cn> Date: Wed, 17 Jun 2026 16:52:52 +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 v9 0/4] mm/page_owner: add per-fd 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: <20260525081652.2210206-1-zhen.ni@easystack.cn> <20260525125819.1857f215bc56b26a0727bedc@linux-foundation.org> From: "zhen.ni" In-Reply-To: <20260525125819.1857f215bc56b26a0727bedc@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Tid: 0a9ed4c88a4a0229kunm6cbe07ca9d54e X-HM-MType: 1 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFJQjdXWRgWCB1ZQUpXWS1ZQUlXWQ8JGhUIEh9ZQVlCQkIfVkgaQkpNTx1CT04YGVYVFA kWGhdVGRETFhoSFyQUDg9ZV1kYEgtZQVlJSkNVQk9VSkpDVUJLWVdZFhoPEhUdFFlBWU9LSFVKS0 lPT09IVUpLS1VKQktLWQY+ 在 2026/5/26 03:58, Andrew Morton 写道: > On Mon, 25 May 2026 16:16:48 +0800 Zhen Ni wrote: > >> This patch series introduces per-file-descriptor filtering capabilities to the >> page_owner feature. > > Thanks again. AI review has found a bunch of new things to get worried > about: > https://sashiko.dev/#/patchset/20260525081652.2210206-1-zhen.ni@easystack.cn > > Hi, Can this lead to an out-of-bounds memory read? The NUMA filter in page_owner (mm/page_owner.c:790-798) bypasses PF_POISONED_CHECK() to avoid triggering VM_BUG_ON during concurrent page allocation/free: int page_nid = memdesc_nid(page->flags); When NODE_NOT_IN_PAGE_FLAGS is defined, memdesc_nid() performs unchecked array access: int memdesc_nid(memdesc_flags_t mdf) { return section_to_node_table[memdesc_section(mdf)]; } If page->flags is poisoned, memdesc_section() can return a garbage section_nr that causes out-of-bounds access. ## Lockless Access Safety Principle The page_owner iterator runs without locks, meaning pages can be allocated or freed concurrently. The fundamental design principle should be: "It's acceptable to skip a small number of abnormal pages, but panics must be prevented." In lockless iteration, TOCTOU is unavoidable - even with reference counting or RCU, page->flags can still be modified concurrently during access. Zone locks prevent this but are prohibitively expensive. ## Proposed Solution: Add nid to struct page_owner Record nid at allocation time when page state is stable, eliminating the need to extract it from page->flags during iteration: ### 1. Modify struct page_owner struct page_owner { unsigned short order; short last_migrate_reason; ... pid_t tgid; pid_t free_pid; pid_t free_tgid; int nid; // NEW }; ### 2. Record nid during allocation static inline void __update_page_owner_handle(struct page *page, ...) { int nid = page_to_nid(page); // Safe in allocation context for_each_page_ext(page, 1 << order, page_ext, iter) { page_owner = get_page_owner(page_ext); page_owner->nid = nid; // ... other fields ... } } ### 3. Use saved nid in NUMA filter if (state->nid_filter_enabled) { int page_nid = page_owner->nid; // Direct read, safe if (!node_isset(page_nid, state->nid_filter)) { spin_unlock_irqrestore(&state->lock, flags); goto ext_put_continue; } } ### 4. Update nid on page migration // In split_page_owner() when page migrates page_owner->nid = page_to_nid(&newfolio->page); The remaining two issues can also be improved. If there are no additional comments, I will proceed with sending v10. Thanks, Zhen