From: Al Viro <viro@zeniv.linux.org.uk>
To: Xin Zhao <jackzxcui1989@163.com>
Cc: brauner@kernel.org, alex.aring@gmail.com, allen.lkml@gmail.com,
arnd@arndb.de, chuck.lever@oracle.com, david@kernel.org,
ebiederm@xmission.com, j.granados@samsung.com, jack@suse.cz,
jlayton@kernel.org, keescook@chromium.org,
linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, ljs@kernel.org,
mcgrof@kernel.org, mjguzik@gmail.com, pfalcato@suse.de,
rppt@kernel.org
Subject: Re: [PATCH v4] coredump: Add /proc/<pid>/coredump_pre_exit for pre-exit before dumping
Date: Thu, 25 Jun 2026 17:55:50 +0100 [thread overview]
Message-ID: <20260625165550.GN2636677@ZenIV> (raw)
In-Reply-To: <20260625085018.989584-1-jackzxcui1989@163.com>
On Thu, Jun 25, 2026 at 04:50:18PM +0800, Xin Zhao wrote:
> > [Severity: Medium]
> > Similar to the issue in exit_mmap_mapped_shared(), this non-atomic update
> > of file->f_flags risks losing concurrent fcntl() updates since it doesn't
> > hold file->f_lock.
> >
> > Also, if a file has duplicated file descriptors (e.g., via dup()), will
> > clearing O_TMPCLOS here prematurely skip the closure of the remaining
> > descriptors? When encountering the duplicated descriptor later, the flag
> > will already be cleared, leaving the shared file actively referenced.
>
> Currently, this flag will only be used by the logic we added, so I believe
> there won't be any issues.
What makes you (or whatever LLM you happen to use) think that file is referenced
only by descriptor table of the coredumping process? Or that only one coredumping
process exists at any time, for that matter - and each might hold references to
the same struct file.
next prev parent reply other threads:[~2026-06-25 16:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260624145552.70143-1-jackzxcui1989@163.com>
2026-06-25 7:28 ` [PATCH v4] coredump: Add /proc/<pid>/coredump_pre_exit for pre-exit before dumping Christian Brauner
2026-06-25 8:50 ` Xin Zhao
2026-06-25 16:55 ` Al Viro [this message]
2026-06-25 10:57 ` David Hildenbrand (Arm)
2026-06-25 11:18 ` Pedro Falcato
2026-06-25 11:43 ` David Hildenbrand (Arm)
2026-06-25 12:48 ` Lorenzo Stoakes
2026-06-25 15:45 ` Xin Zhao
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=20260625165550.GN2636677@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=david@kernel.org \
--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=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mcgrof@kernel.org \
--cc=mjguzik@gmail.com \
--cc=pfalcato@suse.de \
--cc=rppt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox