From: Oleg Nesterov <oleg@redhat.com>
To: Christian Brauner <brauner@kernel.org>
Cc: NeilBrown <neil@brown.name>,
linux-fsdevel@vger.kernel.org, Jann Horn <jannh@google.com>,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
Xin Zhao <jackzxcui1989@163.com>,
Mateusz Guzik <mjguzik@gmail.com>,
Jeff Layton <jlayton@kernel.org>, Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH RFC v4 15/18] coredump: add COREDUMP_CLOSE_FILES
Date: Sat, 26 Sep 2026 13:52:51 +0200 [thread overview]
Message-ID: <areyEy7TkYFYHE7_@redhat.com> (raw)
In-Reply-To: <20260925-kundgeben-kopfnicken-katapultieren-85e8f57ef815@brauner>
On 09/25, Christian Brauner wrote:
>
> On Thu, Sep 24, 2026 at 04:47:45PM +0200, Oleg Nesterov wrote:
> >
> > I don't understand this smp_store_release() and smp_load_acquire() in
> > coredump_task_exit().
> >
> > Both wake_up_process() and set_current_state() have the necessary barriers,
> > see the comment above set_current_state(). So it seems that we can use the
> > plain store/load.
>
> Oh, I wasn't clear on that.
>
> > But what I really can't understand is why coredump_close_files() can't just
> > do switch_files_struct() itself. It could do override_creds(ct->task->cred)
> > if this is one of the reasons.
>
> It can, it just felt cleaner to let the individual tasks do it. But I
> have deferred that part of the patch series until we got the synchronous
> close in.
OK, we can return to this later.
As I said, the patch looks correct to me, so FWIW
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
next prev parent reply other threads:[~2026-09-26 11:53 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-10 15:47 [PATCH RFC v4 00/18] coredump, files: exit files on request Christian Brauner
2026-09-10 15:47 ` [PATCH RFC v4 01/18] fs: don't open-code file_close_fd() in close_fd() Christian Brauner
2026-09-10 15:48 ` [PATCH RFC v4 02/18] fs: add switch_files_struct() Christian Brauner
2026-09-10 15:48 ` [PATCH RFC v4 03/18] fs: move unshare_fd() to fs/file.c Christian Brauner
2026-09-10 15:48 ` [PATCH RFC v4 04/18] fs: remove unshare_files() Christian Brauner
2026-09-10 15:48 ` [PATCH RFC v4 05/18] fs: add filp_close_sync() Christian Brauner
2026-09-10 15:48 ` [PATCH RFC v4 06/18] fs: make close_files() synchronous Christian Brauner
2026-09-10 15:48 ` [PATCH RFC v4 07/18] fs: make close_range() synchronous Christian Brauner
2026-09-10 15:48 ` [PATCH RFC v4 08/18] fs: rename do_close_on_exec() to close_cloexec_files() Christian Brauner
2026-09-10 15:48 ` [PATCH RFC v4 09/18] fs: make close_cloexec_files() synchronous Christian Brauner
2026-09-24 12:07 ` Oleg Nesterov
2026-09-10 15:48 ` [PATCH RFC v4 10/18] coredump: drop core_state->dumper Christian Brauner
2026-09-23 15:27 ` Oleg Nesterov
2026-09-10 15:48 ` [PATCH RFC v4 11/18] sched: add wait_var_event_state() Christian Brauner
2026-09-23 15:28 ` Oleg Nesterov
2026-09-10 15:48 ` [PATCH RFC v4 12/18] coredump: replace the startup completion with a thread count Christian Brauner
2026-09-23 15:28 ` Oleg Nesterov
2026-09-10 15:48 ` [PATCH RFC v4 13/18] coredump: factor out coredump_wait_inactive() Christian Brauner
2026-09-23 15:29 ` Oleg Nesterov
2026-09-10 15:48 ` [PATCH RFC v4 14/18] fs: add alloc_files_struct() Christian Brauner
2026-09-10 15:48 ` [PATCH RFC v4 15/18] coredump: add COREDUMP_CLOSE_FILES Christian Brauner
2026-09-24 14:47 ` Oleg Nesterov
2026-09-25 16:01 ` Christian Brauner
2026-09-26 11:52 ` Oleg Nesterov [this message]
2026-09-10 15:48 ` [PATCH RFC v4 16/18] coredump: cancel io_uring requests before closing files Christian Brauner
2026-09-10 15:48 ` [PATCH RFC v4 17/18] tools: sync coredump.h header Christian Brauner
2026-09-10 15:48 ` [PATCH RFC v4 18/18] selftests/coredump: test COREDUMP_CLOSE_FILES Christian Brauner
2026-09-10 23:48 ` [PATCH RFC v4 00/18] coredump, files: exit files on request NeilBrown
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=areyEy7TkYFYHE7_@redhat.com \
--to=oleg@redhat.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=jackzxcui1989@163.com \
--cc=jannh@google.com \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mjguzik@gmail.com \
--cc=neil@brown.name \
--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.