From nobody Mon Jun 8 13:25:32 2026 Received: from mail-dl1-f66.google.com (mail-dl1-f66.google.com [74.125.82.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 01BBD33ADA8 for ; Fri, 29 May 2026 02:01:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.66 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780020075; cv=none; b=V3/lwnyL+d2gZv5wQhFr5vflT09AdfFgf2DZC6SmudRcWhz9njSiKcF57/hZhR49BbBusFqsA3uwfN4TZk5ZC8/Sx2H0hBaoIJjg6epeetngbRuq7CxL98/XIjCELrpdbcoMa7cq13FDMhB8cbq0OT4CJf5BruKQD5h/wLDJZwI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780020075; c=relaxed/simple; bh=NSlApGxbM5wb+5Cvd4wdXDhv6wVAUpLYQaKdCfgZjq8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RDManW0GCnlGYvsbXf9cYtMUueNlBX+d7R7HaJ2UZGOsoswFcUjLyN0n8aCijUtSO8kdHG9zzhaY9ruInHEPAO9plk4IH7nmECXAbc9j/aNyqBigygPdm/2XPT2Tqs8loHnqDLnJrdA8dqNpa2IzldYnmEA9xc/yvM0cf7KMZwI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=SmcWyLSf; arc=none smtp.client-ip=74.125.82.66 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SmcWyLSf" Received: by mail-dl1-f66.google.com with SMTP id a92af1059eb24-132830d8281so880575c88.1 for ; Thu, 28 May 2026 19:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780020073; x=1780624873; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=3IzqEcZZW6Ni5x3xFqs4GNiWd+yExlx9lPD7PThYV7c=; b=SmcWyLSfu7Un37rKeXUhIqjHf8zbRB69aZe3M/+f8+IgDYeoXEGhysSS5qSJgexOjv g5PjHyk1YBfUZIn+CuFl/ovQsv3Gt9x3v+EsqpzfmIpmC0HozLIA+TSH2eYdXE714Pgn Bt6bKNhlYGZLRrZdTrn8ZKoKJypdFxVr3O+uDa9wBimz555P0VHYjjbaRy89kldNr0m4 Y2PDHcSS0HiVjfgEqIzrEe+f+ImQ8vXmjuqxP0poLACrh0vkDX3WvbvSO7Vi/crhNy3k Ak0uRuaBIyie5RCFMeuLYbeXIDSKmg5jmV0Xj19ltwJorgpBQUi454UsgXnE8N/4fvqv PqUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780020073; x=1780624873; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3IzqEcZZW6Ni5x3xFqs4GNiWd+yExlx9lPD7PThYV7c=; b=ZcFAR0EzgECPMvvcS58YOeD080apaZvr2hNc6H4QvpD6J4sQyU+1/Izun2fEBx8IDc Hsoh11XrNVFkBW4Z3Yavdi5ARWbRan34qjHAPN3iIiq/ffW1dlpuETCvdKqhF6bl7n7O LyNNbO5dkIcUlOeSmTrZJwDzynoZ2y8PPsaCedCG6jX1Pg3B6ITlyQUJ3DOIRt9xVuKe /XCBe+SJgSBGOT9OHX3XpAW2SYmqNzZ9di99tI4eW76no4SJb8mOpSm0rbgBklnFcJt7 KOQ9LfVIDRjMwqw4yPqPR2cjECGZplKORv03oJqhq6jDkw6HeLBXl2wWlyhmY5IkF9wH ql8w== X-Forwarded-Encrypted: i=1; AFNElJ+Od5V6hqzQe2HpeMUszkx5kh6JN0QD9ilIOo7DDd4+osNeVtIuHR01Pb9eD69zqHzqUlzk9RPZ+c08aXc=@vger.kernel.org X-Gm-Message-State: AOJu0Yy5JaSWohc6rQmbKBdTL1mvE4gZm1ePTBmyF2sL9/ABIO5giWOP ykgZOgxuAWo/UIYaS3Rx5Tv7FrnHmiyb65t+ZA+SkquYfBlYJCYDrmmD X-Gm-Gg: Acq92OHGPjlev2JaDssqj/YJck0kraUk4htDoJ36tIGmnokI2djwdiIyWqTZy4JFUAJ o72fzYn0duuW6J6B3NG2vNc4rFLIF1s7ftb2kFbaTe0obErTjKhrdkUEsYz1b14fSKsw4vdc7EE bHY+qPuuA9oXbSjrfzjsAqi5flVeXZL0zrWKTibh5XuFpb9p8mOtfWAcSLASHt8GRVrPWGvfMTP OfcRLEc1jCqr0AQZuzTWIsO8mDKvJ0dbJGC5pDq3dG21DLG7mXedHE64sbiuk36WWplbxiwPry8 3EdRX5AUs7Y73Ntar5UpcnAoGhZVWxdh90T37avVLPagLMymTZQ8qyEeMUAf1Y4OOGVjwayRM0j P0ebVmctG0iLccGb5vyrZPZHqwWYE/n5+KTj7mTPm3K72Bl+sQC7bpw02CVTCuV22dSYblbTiLn QXKynqGkn9X7pXwbJ+M7UOAsEoqz+hXw== X-Received: by 2002:a05:7022:f96:b0:12f:c7c3:f5ab with SMTP id a92af1059eb24-137ae975bafmr379758c88.2.1780020073032; Thu, 28 May 2026 19:01:13 -0700 (PDT) Received: from anonyme ([2605:52c0:2:2f27:be24:11ff:fe89:6f0f]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-137b3c7fd47sm255135c88.14.2026.05.28.19.01.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2026 19:01:12 -0700 (PDT) From: AnonymeMeow To: brauner@kernel.org Cc: amir73il@gmail.com, jack@suse.cz, repnop@google.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, AnonymeMeow Subject: [PATCH v2] fanotify: report thread pidfds for FAN_REPORT_TID Date: Fri, 29 May 2026 10:00:35 +0800 Message-ID: <20260529020035.17477-1-anonymemeow@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260528-schmuckvoll-heilen-garen-be77b4208671@brauner> References: <20260528-schmuckvoll-heilen-garen-be77b4208671@brauner> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The FAN_REPORT_PIDFD and FAN_REPORT_TID flags used to be mutually exclusive because by the time the pidfd support was introduced to fanotify, pidfds could only be created for thread group leaders. Now that the pidfd API supports thread-specific pidfds via PIDFD_THREAD, this restriction can be lifted. Also drop the pid_has_task() check to allow pidfds to be reported for reaped tasks as well. Link: https://lore.kernel.org/lkml/20260528-schmuckvoll-heilen-garen-be77b4= 208671@brauner/ Signed-off-by: AnonymeMeow --- On 2026-05-28 13:51 +0200, Christian Brauner wrote: > For quite a while the kernel refused to hand out pidfds for reaped > processes even if the struct pid was pinned like in this case. >=20 > But that makes various APIs - including this one - way less powerful > than they can be. Nowadays the socket layer already hands out pidfds for > reaped processes. It also stashed the struct pid. Let's do the same > here. >=20 > Drop the pid_has_task() change and then: >=20 > pidfd =3D pidfd_prepare(event->pid, pidfd_flags | PIDFD_STALE, &pidfd_fil= e); >=20 > which instructs pidfs to and out a pidfd even if the task has already > been reaped. Reaped pidfds can still be queried for various types of > information that is kept around even if the task is long gone. Thanks for the review. I've updated this in v2 as you suggested. Also, the LTP fanotify21 test currently explicitly expects ESRCH or FAN_NOPIDFD for exited processes. I will update that test case accordingly. With Best Regards, AnonymeMeow --- fs/notify/fanotify/fanotify_user.c | 33 +++++++----------------------- 1 file changed, 7 insertions(+), 26 deletions(-) diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanoti= fy_user.c index ae904451dfc0..b604e3da58ad 100644 --- a/fs/notify/fanotify/fanotify_user.c +++ b/fs/notify/fanotify/fanotify_user.c @@ -19,6 +19,7 @@ #include #include #include +#include =20 #include =20 @@ -903,25 +904,13 @@ static ssize_t copy_event_to_user(struct fsnotify_gro= up *group, metadata.fd =3D fd >=3D 0 ? fd : FAN_NOFD; =20 if (pidfd_mode) { - /* - * Complain if the FAN_REPORT_PIDFD and FAN_REPORT_TID mutual - * exclusion is ever lifted. At the time of incoporating pidfd - * support within fanotify, the pidfd API only supported the - * creation of pidfds for thread-group leaders. - */ - WARN_ON_ONCE(FAN_GROUP_FLAG(group, FAN_REPORT_TID)); + unsigned int pidfd_flags =3D PIDFD_STALE; =20 - /* - * The PIDTYPE_TGID check for an event->pid is performed - * preemptively in an attempt to catch out cases where the event - * listener reads events after the event generating process has - * already terminated. Depending on flag FAN_REPORT_FD_ERROR, - * report either -ESRCH or FAN_NOPIDFD to the event listener in - * those cases with all other pidfd creation errors reported as - * the error code itself or as FAN_EPIDFD. - */ - if (metadata.pid && pid_has_task(event->pid, PIDTYPE_TGID)) - pidfd =3D pidfd_prepare(event->pid, 0, &pidfd_file); + if (FAN_GROUP_FLAG(group, FAN_REPORT_TID)) + pidfd_flags |=3D PIDFD_THREAD; + + if (metadata.pid) + pidfd =3D pidfd_prepare(event->pid, pidfd_flags, &pidfd_file); =20 if (!FAN_GROUP_FLAG(group, FAN_REPORT_FD_ERROR) && pidfd < 0) pidfd =3D pidfd =3D=3D -ESRCH ? FAN_NOPIDFD : FAN_EPIDFD; @@ -1628,14 +1617,6 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, = unsigned int, event_f_flags) #endif return -EINVAL; =20 - /* - * A pidfd can only be returned for a thread-group leader; thus - * FAN_REPORT_PIDFD and FAN_REPORT_TID need to remain mutually - * exclusive. - */ - if ((flags & FAN_REPORT_PIDFD) && (flags & FAN_REPORT_TID)) - return -EINVAL; - /* Don't allow mixing mnt events with inode events for now */ if (flags & FAN_REPORT_MNT) { if (class !=3D FAN_CLASS_NOTIF) --=20 2.54.0