mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: fujo <hooyan2024@gmail.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: linux-fsdevel@vger.kernel.org,
	Christian Brauner <brauner@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] pidfs: don't report autoreaped tasks readable before exit info exists
Date: Sat, 17 Oct 2026 15:23:10 -0400	[thread overview]
Message-ID: <179226499044.847.6888435030853836469@gmail.com> (raw)
In-Reply-To: <20261017054356.7874-1-hooyan2024@gmail.com>

Hi Oleg,

thanks, and sorry for the unclear report.  You are right that the early
wakeup is not specific to CLONE_AUTOREAP: exit_notify() always calls
do_notify_pidfd() for an exiting non-delay_group_leader, so pollers are
woken and pidfd_poll() returns EPOLLIN as soon as exit_state is set.

What I observed is the window between that first wakeup and
release_task() -> pidfs_exit() publishing PIDFS_ATTR_BIT_EXIT: poll()
returns EPOLLIN to userspace at that point (it does not wait for the
later wake_up_all() after the unhash), so a parent that follows the
"poll and then PIDFD_GET_INFO" sequence from the series description can
read a mask without PIDFD_INFO_EXIT.  The second wakeup only helps
pollers that are still asleep when it happens.

Test-case details, as requested:

- clone3(CLONE_PIDFD | CLONE_AUTOREAP, exit_signal = 0, pidfd = &pidfd)
- mode 0: the child creates one thread which exits after 500us and then
  exits itself with 42; mode 1: the child exits immediately
- parent: poll(pidfd, POLLIN, 5000), then
  ioctl(pidfd, PIDFD_GET_INFO, {.mask = PIDFD_INFO_EXIT}) and counts
  results whose mask lacks PIDFD_INFO_EXIT
- x86_64 mainline 58161ead29e5 (v7.3-rc7), defconfig + KASAN + DEBUG_INFO
  + DEBUG_KMEMLEAK, QEMU, 2G:
    mode 0, SMP 2: 18/300
    mode 0, SMP 1: 78/300
    mode 1, SMP 2:  8/300
- the in-tree pidfd_autoreap_test global.autoreap_multithreaded case
  fails the same way: its poll() gets POLLIN and PIDFD_GET_INFO returns
  mask 0x7 (PID|CREDS|CGROUPID) without EXIT.

Your POLLHUP remark resolves it: PIDFD_INFO_EXIT is published before the
task linkage is removed, so POLLHUP is the right condition to wait for.
I changed the autoreap tests to pfd.events = POLLHUP and to check
POLLHUP in revents; on the *unpatched* kernel they now pass ten
consecutive runs (19/19 each), and a POLLHUP variant of the reproducer
gets 300/300 with PIDFD_INFO_EXIT.  So the kernel behaves as designed
and the tests were wrong.

I will withdraw the kernel patch and send a selftests-only v2.  Do you
think the CLONE_AUTOREAP cover letter or some KAPI comment should also
say explicitly that POLLHUP, not POLLIN, guarantees that
PIDFD_INFO_EXIT is available?  The "poll the pidfd and retrieve the exit
status via PIDFD_GET_INFO" wording is what led me there.

Thanks,
fujo

  parent reply	other threads:[~2026-10-17 19:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-17  5:43 fujo
2026-10-17 13:48 ` Oleg Nesterov
2026-10-17 19:23 ` fujo [this message]
2026-10-17 19:23 ` [PATCH v2] selftests/pidfd: wait for POLLHUP before reading exit info fujo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=179226499044.847.6888435030853836469@gmail.com \
    --to=hooyan2024@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®