Re: [PATCH] coredump/fcntl: Add FD_CLOBCOR flag to close fd before dumping core

[Xin Zhao]

On Thu, 18 Jun 2026 05:30:54 +0100 Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:

> 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?

Thank you for your response. I developed and tested this feature in 6.1.158,
but I made this serious mistake when porting it to linux-next. I should have
retained the xchg operation that was still present in 6.1.158 to retrieve
fdt->fd[i].


> 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.

I see.
The overhead introduced by this patch comes from the additional memory
allocation for the bitmap during process initialization, as well as the
extra traversal time during coredump_wait(). I need to think of ways to
achieve this with minimal cost, and then you can take another look at it.

Thanks
Xin Zhao