From: Al Viro <viro@zeniv.linux.org.uk>
To: Xin Zhao <jackzxcui1989@163.com>
Cc: brauner@kernel.org, jack@suse.cz, jlayton@kernel.org,
chuck.lever@oracle.com, alex.aring@gmail.com, arnd@arndb.de,
ebiederm@xmission.com, 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 05:30:54 +0100 [thread overview]
Message-ID: <20260618043054.GY2636677@ZenIV> (raw)
In-Reply-To: <20260618030700.2511668-1-jackzxcui1989@163.com>
On Thu, Jun 18, 2026 at 11:07:00AM +0800, Xin Zhao wrote:
> 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.
>
> 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.
>
> We actually considered using signals that generate coredumps to perform
> the actions we wanted in user space. However, since other threads within
> the process are not frozen when handling these signals, indiscriminately
> closing an fd can lead to concurrency issues. For example, if the thread
> that triggered the coredump closes the fd in the signal handler while
> other threads are using the resources associated with that fd, it could
> cause secondary corruption of the coredump state.
>
> Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
No. Leaving aside the unasked-for overhead for every process on every system,
whether they are interested in this "feature" or not, this
> +static struct fdtable *close_files_before_core(struct files_struct *files)
> +{
> + /*
> + * It is safe to dereference the fd table without RCU or
> + * ->file_lock because this is the last reference to the
> + * files structure.
> + */
> + struct fdtable *fdt = rcu_dereference_raw(files->fdt);
> + unsigned int i, j = 0;
> +
> + for (;;) {
> + unsigned long set;
> +
> + i = j * BITS_PER_LONG;
> + if (i >= fdt->max_fds)
> + break;
> + set = fdt->open_fds[j++];
> + while (set) {
> + if (set & 1 && close_before_core(i, files)) {
> + struct file *file = fdt->fd[i];
> +
> + if (file) {
> + filp_close(file, files);
> + cond_resched();
> + }
> + }
> + i++;
> + set >>= 1;
> + }
> + }
is just plain wrong. You are leaving references in that descriptor table,
whether you've closed them or not. It *can't* be right - no matter what
you do after having called that, you will either leak file references
for ones that were not closed or eat double-free for ones that were.
Have you actually tested that patch?
Note that above is _not_ "fix that thing and I'll have no objections";
I think the benefits of that API are nowhere near worth inflicting the
cost on everyone.
next prev parent reply other threads:[~2026-06-18 4:31 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 [this message]
2026-06-18 4:58 ` Xin Zhao
2026-06-18 5:29 ` Eric W. Biederman
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=20260618043054.GY2636677@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=alex.aring@gmail.com \
--cc=allen.lkml@gmail.com \
--cc=arnd@arndb.de \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=ebiederm@xmission.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 \
/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.