Re: [PATCH v6] coredump: Add bit 9 of coredump_filter for pre-exit files before dumping

On Thu, Aug 06, 2026 at 04:01:55PM +0200, David Hildenbrand (Arm) wrote:
> On 8/4/26 02:17, Xin Zhao wrote:
> > A coredump typically takes seconds or even longer to complete. If we
> > happen to hold a write lock with flock just before triggering the
> > coredump, that write lock will not be released during the entire coredump
> > process. As a result, other processes attempting to acquire the same write
> > lock may experience significant delays. Another typical scenario is that
> > some custom management modules for shared memory also need to release the
> > reference counts of the related buffers as soon as possible, rather than
> > waiting until the coredump is complete.
> > 
> > Add a new bit(9) of coredump_filter to tag whether need to dump fd list.
> > We set it by default because tools like systemd-coredump go through the
> > fds. Some other coredump pipe programs like minicoredump do not use fds by
> > default. If you are sure that your coredump backend does not use the fds,
> > you can clear bit 9, which will allow some file resources without VMA
> > references to be released earlier.
> > 
> > In fput(), check FP_DUMPCORE task flags to NOT release file by task work,
> > otherwise file put operation will NOT execute util coredump finish.
> > 
> > Test Case One - flock
> > Test program send signal SIGABRT to the program which owns the flock,
> > output the wait time(unit ms) to successfully attach the flock.
> > Test program malloc 500MB heap and memset it.
> > If NOT set bit9 of coredump_filter, waitms is 11280.
> > If set bit9 of coredump_filter, waitms is 0.
> > 
> > Test Case Two - ion buffer
> > Test programs include ion buffer publisher and ion buffer subscriber.
> > Ion buffer publisher output the ion buffer hold_time if the subscriber
> > NOT send ack to publisher and NOT release it. The subscriber will trig
> > coredump by itself in some time.
> > If NOT set bit9 of subscriber coredump_filter, max hold_time is 19591ms.
> > If set bit9 of subscriber coredump_filter, max hold_time is 320ms.
> > 
> > Signed-off-by: Xin Zhao <[email protected]>
> > ---
> > 
> > Change in v6:
> > - Fix operator precedence in PF_KTHREAD/PF_DUMPCORE check.
> > 
> > Change in v5:
> > - Not add another bootargs for the feature,
> >   as suggested by Christian Brauner and Lorenzo Stoakes.
> >   Add bit9 of coredump_filter to tag whether need to dump fd list.
> >   Set bit9 to 1 as default.
> > - Al Viro, Christian Brauner and Lorenzo Stoakes point out so many
> >   problems of the code related to umap that was added in v4, delete all of
> >   it which is unnecessary. The management of reference counting for shared
> >   memory generally does not need to be released through the release
> >   operation of files that have VMA references. Traversing all the threads
> >   within the process and executing exit_files() is sufficient.
> > - Fulfill comments and commit log,
> >   as suggested by Pedro Falcato and Lorenzo Stoakes.
> > - Link to v5: https://lore.kernel.org/all/[email protected]/
> > 
> > Change in v4:
> > - Christian pointed out that the coredump process will traverse file
> >   descriptors (fd), so certain fds should not be closed by default.
> >   Rework the whole feature, add /proc/<pid>/coredump_pre_exit for user
> >   pre-exit resources selection, default is NOT pre-exit anything.
> > - Mateusz suggested that walking the fd table and release the file-lock is
> >   reasonable. No longer release all the fd(s). Based on user config, only
> >   the flock fd(s) and the fd(s) correspondent to file-backed shared memory
> >   will be released at most.
> > - Link to v4: https://lore.kernel.org/all/[email protected]/
> > 
> > Change in v3:
> > - Add comment and commit-log to explain why do the MMF_DUMP_MAPPED_SHARED
> >   mm_flags_test() check, note that memory mapped files keep their own
> >   separate references to the files. The case to work around is that early
> >   unlocking a flock on a file allows other processes to lock and modify
> >   the mapped data protected by the flock,
> >   as suggested by Pedro Falcato.
> > - Link to v3: https://lore.kernel.org/all/[email protected]/
> > 
> > Change in v2:
> > - Get rid of the implement of adding new fcntl API, the issue does not
> >   worth inflicting the cost on everyone,
> >   as suggested by Al Viro.
> > - Call exit_files() in coredump_wait(),
> >   as suggested by Eric W. Biederman.
> >   Add MMF_DUMP_MAPPED_SHARED mm_flags_test() check to filter cases that
> >   need to dump file-backed shared memory.
> > - Link to v2: https://lore.kernel.org/lkml/[email protected]/
> > 
> > v1:
> > - Link to v1: https://lore.kernel.org/all/[email protected]/
> > ---
> >  Documentation/filesystems/proc.rst | 14 ++++++++++++--
> >  fs/coredump.c                      | 21 +++++++++++++++++++++
> >  fs/file_table.c                    |  7 ++++++-
> >  include/linux/mm_types.h           |  6 ++++--
> >  4 files changed, 43 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
> > index db6167bef..d590a1dda 100644
> > --- a/Documentation/filesystems/proc.rst
> > +++ b/Documentation/filesystems/proc.rst
> > @@ -1939,6 +1939,7 @@ The following 9 memory types are supported:
> >    - (bit 6) hugetlb shared memory
> >    - (bit 7) DAX private memory
> >    - (bit 8) DAX shared memory
> > +  - (bit 9) fd list
> 
> "The following 9 memory types are supported: ... fd list"

Fwiw, I still refuse this patch for the reasons I mentioned in the
various other postings of this...