Re: [PATCH v4 2/2] fanotify: allow reporting pidfds for reaped tasks

[AnonymeMeow]

Sashiko said that pidfs_register_pid() can fail under memory pressure,
since it allocates memory using GFP_KERNEL without a way to pass in
__GFP_NOFAIL. This can cause fanotify_alloc_event() to silently drop
the event even when the group has an unlimited queue length.

Should we make pidfs registration best-effort instead and still return
the allocated event if pidfs_register_pid() fails? But IMO this will
make the API semantically ambiguous. If the kernel guarantees that the
event pid is registered with pidfs when pidfd reporting is requested,
then a later FAN_NOPIDFD or -ESRCH can only be caused by the task being
invisible within the reader's pid namespace. But if we allow best-effort
registration, the event may still carry a pinned struct pid, but pidfs
registration may have failed due to memory pressure. If userspace reads
the event after the task has been reaped, it still gets a FAN_NOPIDFD
or -ESRCH due to failed pidfs registration caused by memory pressure,
IMO this should be reported as a -ENOMEM instead of -ESRCH. But
currently it seems we don't have a good way to register the pid with
__GFP_NOFAIL or __GFP_RETRY_MAYFAIL, so what would be the preferred
approach to handle this situation?