From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-m3268.qiye.163.com (mail-m3268.qiye.163.com [220.197.32.68]) (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 50826800 for ; Sat, 9 May 2026 07:30:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.32.68 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778311859; cv=none; b=APDuP82rJA1uXS2iyF/UCEly7bpVjhhO9T1YCly9QXjMKG2Ry09/VQKjJyGnVfcEUgmTa90QgZicy3KutI/f7NTuGFgM8tNwFSKrTqmZxKGDsXuHYSBvZFc7L7KiJKJ0l8Qbf0L5In/gIOs3ZjBsg9TEAb4llQX7lAgothx1RUk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778311859; c=relaxed/simple; bh=EkznmhHSWjzYZpQ+2M/qNhkPCeIXEr3HjxHyTonNeco=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=s4k8HXr7fRQ66taXBGdsXS69MC5LKvlmUtJKKFR+CV+L0ml6WTeymp/YwE+Z+ZfK7doYjOkgVz57o5z9wxJCX6EQ3YbmpC+1511wbCN+B31QY8JJUl6MinNFazfhDXbPnBdtk/9jCo3bV+XgwaIhxzMtSoIgwzIUz+/ISkFn64Y= 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.68 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 19e78b935; Sat, 9 May 2026 14:54:58 +0800 (GMT+08:00) Message-ID: Date: Sat, 9 May 2026 14:54:58 +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 v5 1/3] mm/page_owner: add print_mode filter To: SeongJae Park Cc: akpm@linux-foundation.org, 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: <20260509002902.83937-1-sj@kernel.org> From: "zhen.ni" In-Reply-To: <20260509002902.83937-1-sj@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Tid: 0a9e0b8493e80229kunm86e998da2622e9 X-HM-MType: 1 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFJQjdXWRgWCB1ZQUpXWS1ZQUlXWQ8JGhUIEh9ZQVlCGBhJVhoYSEpIHUJPTk0YQlYVFA kWGhdVGRETFhoSFyQUDg9ZV1kYEgtZQVlJSkNVQk9VSkpDVUJLWVdZFhoPEhUdFFlBWU9LSFVCQk lOS1VKS0tVSkJLQlkG 在 2026/5/9 08:29, SeongJae Park 写道: > On Thu, 7 May 2026 14:46:41 +0800 Zhen Ni wrote: > >> Add a print_mode filter to page_owner that allows users to choose between >> printing full stack traces or only stack handles, significantly reducing >> output size for debugging and analysis. >> >> The filter provides a string-based interface under >> /sys/kernel/debug/page_owner_filter/: >> - Reading shows the current mode with [] brackets around active option >> - Writing accepts "full_stack" or "stack_handle" strings >> >> The default full_stack mode maintains backward compatibility with existing >> usage, displaying complete stack traces for each page allocation. >> >> The stack_handle mode dramatically reduces log size by showing only >> the handle number instead of the full stack trace. The mapping from >> handles to actual stack traces can be obtained via the >> show_stacks_handles interface. >> >> Example usage: >> # echo stack_handle > /sys/kernel/debug/page_owner_filter/print_mode >> # cat /sys/kernel/debug/page_owner_filter/print_mode >> full_stack [stack_handle] >> # cat /sys/kernel/debug/page_owner >> Page allocated via order 0, migratetype Unmovable, gfp_mask 0x1100ca, >> pid 1, tgid 1 (systemd), ts 123456789 ns >> PFN 0x1000 type Unmovable Block 1 type Unmovable >> Flags 0x3fffe800000084(referenced|lru|active|private|node=0|zone=1) >> handle: 17432583 >> ... >> >> Signed-off-by: Zhen Ni > > I added a few trivial comments below, but overall looks good to me. > > Reviewed-by: SeongJae Park > >> --- >> >> Changes in v5: >> - No code changes >> >> Changes in v4: >> - Change from numeric (0/1) to string-based interface ("full_stack"/"stack_handle") >> - Merge infrastructure patch into this patch >> >> Changes in v3: >> - No code changes >> >> Changes in v2: >> - Renamed from 'compact mode' to 'print_mode' for better clarity >> - Use enum values (0=full_stack, 1=stack_handle) instead of boolean >> - Update debugfs filename from 'compact' to 'print_mode' > > Adding links to previous revisions would be helpful. Good point. I will add lore links to all previous revisions in v6. > >> --- >> mm/page_owner.c | 93 +++++++++++++++++++++++++++++++++++++++++++++++-- >> 1 file changed, 91 insertions(+), 2 deletions(-) >> >> diff --git a/mm/page_owner.c b/mm/page_owner.c >> index 8178e0be557f..28766c854d02 100644 >> --- a/mm/page_owner.c >> +++ b/mm/page_owner.c > [...] >> @@ -575,7 +594,11 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn, >> migratetype_names[pageblock_mt], >> &page->flags); >> >> - ret += stack_depot_snprint(handle, kbuf + ret, count - ret, 0); >> + if (READ_ONCE(owner_filter.print_mode) == PAGE_OWNER_PRINT_STACK_HANDLE) { >> + ret += scnprintf(kbuf + ret, count - ret, >> + "handle: %d\n", handle); >> + } else >> + ret += stack_depot_snprint(handle, kbuf + ret, count - ret, 0); > > Braces are unnecessary [2] because both branches have only one statement. > Will fix in v6. > [...] >> +static ssize_t print_mode_write(struct file *file, >> + const char __user *buf, >> + size_t count, loff_t *ppos) >> +{ >> + char *kbuf; >> + int mode; >> + int ret = count; >> + >> + /* >> + * Limit input size. Maximum valid input is "stack_handle" (12 chars) >> + * plus newline and null terminator. Use 32 bytes as a reasonable limit. >> + */ >> + if (count > 32) >> + return -EINVAL; >> + >> + kbuf = kmalloc(count + 1, GFP_KERNEL); >> + if (!kbuf) >> + return -ENOMEM; > > Would it make sense to use kmalloc_objs(), or simply using a local array as > Andrew suggested? I'll use a local array instead. Since the input is limited to 32 bytes, a stack-allocated array should be sufficient and simpler: char kbuf[32 + 1]; Thanks for the review! > > [...] > > [1] https://docs.kernel.org/process/submitting-patches.html#commentary > [2] https://docs.kernel.org/process/coding-style.html#placing-braces-and-spaces > > > Thanks, > SJ > > Best regards, Zhen