From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-m60218.netease.com (mail-m60218.netease.com [210.79.60.218]) (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 C7A17363C6C for ; Tue, 23 Jun 2026 06:24:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=210.79.60.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782195870; cv=none; b=pJgv6BMDjMLMwYtoiElw3xmNkjwZR0EYo3GBe2f/D6ohxbcrvy/7jw/Kzw3YdU7subFqwsTCxvckrMGtk2TNCfjJb7NxKAbjBk7WmbXbhiMXc/Gun0EMEBmaYldak0pQgjORQm3IWmsN5YXnWmsaYjXDgBcQIdtpuF7JqbXr/nk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782195870; c=relaxed/simple; bh=uXvYPT1prxWsMkey2svx2yXokjKXiOqQShJbckcKJAU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cfBxeMP3BB/CEXqC1gdQajhEC0ocmfm3pKgsHg4aab4yXjQJYs8Q26Bwd5tzwpLzx5qtRHYoXwE97eM2x23JGcYSH/dsL5rYFkDZQCJaDZT47diZToTgTn1ktJ3mgN+4YEmPy8j3MjCeaq51gDwGDfB7UaYmnW3vYKeDp41B+HE= 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=210.79.60.218 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 1bc5a41bf; Tue, 23 Jun 2026 14:24:16 +0800 (GMT+08:00) Message-ID: Date: Tue, 23 Jun 2026 14:24:15 +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 v10 3/4] tools/mm: add page_owner_filter userspace tool To: Lance Yang 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: <20260618035750.3724613-4-zhen.ni@easystack.cn> <20260618072103.92397-1-lance.yang@linux.dev> From: "zhen.ni" In-Reply-To: <20260618072103.92397-1-lance.yang@linux.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Tid: 0a9ef326a2fc0229kunm09b7638324d840 X-HM-MType: 1 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFJQjdXWRgWCB1ZQUpXWS1ZQUlXWQ8JGhUIEh9ZQVkZH0lDVhhLGkxNT0JJGU4ZSlYVFA kWGhdVGRETFhoSFyQUDg9ZV1kYEgtZQVlJSkNVQk9VSkpDVUJLWVdZFhoPEhUdFFlBWU9LSFVKS0 lPT09IVUpLS1VKQktLWQY+ 在 2026/6/18 15:21, Lance Yang 写道: > > On Thu, Jun 18, 2026 at 11:57:49AM +0800, Zhen Ni wrote: > [...] >> + /* Read and display filtered output */ >> + ret = 0; >> + while ((ret = read(fd, buf, sizeof(buf))) > 0) { >> + size_t written = fwrite(buf, 1, ret, output); >> + >> + if (written != (size_t)ret) { >> + if (errno == EPIPE) { > > Hmm ... does this work without handling SIGPIPE first? > > With something like: > > $ ./page_owner_filter -m handle | head > > The writer can be killed by SIGPIPE before fwrite() returns EPIPE no? > so this branch would usually not be reached ... > >> + /* Pipe closed, treat as success */ >> + ret = 0; >> + goto out; >> + } >> + perror("write output"); >> + ret = -1; >> + goto out; >> + } >> + } >> + >> + if (ret < 0) { >> + perror("read page_owner"); >> + goto out; >> + } >> + >> + if (fflush(output)) { > > fflush() can also be where the broken pipe is reported, but still treats > EPIPE as an error ... > > Shouldn't we ignore/handle SIGPIPE and treat EPIPE from both fwrite() > and fflush() as succes? > > Cheers, Lance > >> + perror("flush output"); >> + ret = -1; >> + } >> + >> +out: >> + close(fd); >> + if (output != stdout) >> + fclose(output); >> + return ret < 0 ? 1 : 0; >> +} >> -- >> 2.20.1 >> >> > > Thanks for the review. The SIGPIPE handling was indeed incomplete. Without ignoring SIGPIPE first, the process gets killed before fwrite() or fflush() can return EPIPE, so that error branch would never be reached. I've fixed this in v11 by: 1. Adding signal(SIGPIPE, SIG_IGN) at the start of main() 2. Handling EPIPE from both fwrite() and fflush() as success The fix ensures that when the output pipe is closed (e.g., `| head`), the program exits cleanly instead of being terminated by SIGPIPE. Thanks, Zhen