From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Xin Zhao <jackzxcui1989@163.com>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
jlayton@kernel.org, chuck.lever@oracle.com,
alex.aring@gmail.com, arnd@arndb.de, keescook@chromium.org,
mcgrof@kernel.org, j.granados@samsung.com,
allen.lkml@gmail.com, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH] coredump/fcntl: Add FD_CLOBCOR flag to close fd before dumping core
Date: Thu, 18 Jun 2026 00:29:57 -0500 [thread overview]
Message-ID: <87zf0se7qi.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <20260618030700.2511668-1-jackzxcui1989@163.com> (Xin Zhao's message of "Thu, 18 Jun 2026 11:07:00 +0800")
Xin Zhao <jackzxcui1989@163.com> writes:
> A coredump typically takes some time 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.
You are talking about giant processes writing to slow backing store?
I suspect you would be better off quickly writing the coredump to a pipe,
and then writing it to disk.
Unless your machine is badly balanced that should take perhaps a second.
That said I don't see why you need elaborate machinery to do something
about these file descriptors. Unless I am mistaken no file descriptors
are placed into a coredump. In which case it should be possible to just
call exit_files early.
> To address this, we introduce the F_[GET|SET]FD_EX fcntl operation and the
> FD_CLOBCOR flag, allowing coredump_wait() to release any file descriptors
> marked with FD_CLOBCOR. We can also assign the FD_CLOBCOR flag to specific
> shared memory segments, preventing the coredump from including shared
> memory that we are not interested in, thereby reducing both the coredump
> duration and the size of the core file.
Please look at vma_dump_size. There are plenty of ways already to
skip dumping a memory area. Using file backed shared memory,
and madvise(MADV_DONTDUMP) are two easy ones that already exist.
My point is that there are cleaner ways to solve your problem than
the solutions you have proposed.
Eric
next prev parent reply other threads:[~2026-06-18 6:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-18 3:07 [PATCH] coredump/fcntl: Add FD_CLOBCOR flag to close fd before dumping core Xin Zhao
2026-06-18 4:30 ` Al Viro
2026-06-18 4:58 ` Xin Zhao
2026-06-18 5:29 ` Eric W. Biederman [this message]
2026-06-18 6:48 ` Xin Zhao
2026-06-18 6:40 ` [syzbot ci] " syzbot ci
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=87zf0se7qi.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=alex.aring@gmail.com \
--cc=allen.lkml@gmail.com \
--cc=arnd@arndb.de \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=j.granados@samsung.com \
--cc=jack@suse.cz \
--cc=jackzxcui1989@163.com \
--cc=jlayton@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.