Re: [PATCH v3] coredump: exit_files() in coredump_wait() if MMF_DUMP_MAPPED_SHARED is not set

[Xin Zhao]

On Fri, 19 Jun 2026 15:54:26 +0200 Christian Brauner <brauner@xxxxxxxxxx> wrote:

> > +	/*
> > +	 * Early unlocking a flock on a file allows other processes
> > +	 * to lock and modify the mapped data protected by the flock.
> > +	 */
> > +	if (!mm_flags_test(MMF_DUMP_MAPPED_SHARED, tsk->mm))
> > +		exit_files(tsk);
> 
> This doesn't work - at least not unconditionally. Tools like
> systemd-coredump or apport go through the fds. Specifically
> systemd-coredump does:
> 
> 1) /proc/[pid]/fd/ — opendir() then, per entry, readlinkat() to get the symlink target.
> 2) /proc/[pid]/fdinfo/ — for each fd it reads the fdinfo text lines
> 
> The blob is attached to the journal record as the COREDUMP_OPEN_FDS=
> field. So the open-fd list is recorded as metadata, retrievable later
> (e.g. coredumpctl info shows it).
> 
> Also, irc some clever implementations use pidfd_getfd() to preserve the
> files from a coredumping process to preserve them.
> 
> So you break all that - and only in some of the cases which is really
> opaque to userspace. That's not acceptable. If you only care about the
> case where you dump to a file then either special-case it to the legacy
> file coredump format or if it's generally useful make it an optional
> argument that can be passed to the coredump pipe and a new flag
> extension to the coredump socket that makes the coredumping process shed
> it's file descriptors.

Thank you for providing such useful information. I’ve also learned about
the useful pidfd_getfd() interface. Returning to the issue, I really want
to find a suitable method to resolve it. Now I know how to proceed, and I
will modify a version; I would appreciate it if you could take a look at
it later.

Thanks
Xin Zhao