Generic Linux architectural discussions
 help / color / mirror / Atom feed
From: Pedro Falcato <pfalcato@suse.de>
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,  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 v2] coredump: exit_files() in coredump_wait() if MMF_DUMP_MAPPED_SHARED is not set
Date: Thu, 18 Jun 2026 18:19:16 +0100	[thread overview]
Message-ID: <ajQoFeTyIqh6tMVv@pedro-suse> (raw)
In-Reply-To: <ajQXNRT5PnBgh48M@pedro-suse>

On Thu, Jun 18, 2026 at 05:07:56PM +0100, Pedro Falcato wrote:
> On Thu, Jun 18, 2026 at 11:03:01PM +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, call exit_files() in the end of coredump_wait(), if
> > MMF_DUMP_MAPPED_SHARED is not set.
> > 
> > Signed-off-by: Xin Zhao <jackzxcui1989@163.com>
> > ---
> > 
> > Change in v2:
> > - Get rid of the implement of adding new fcntl API, the issue does not
> >   worth inflicting the cost on everyone,
> >   as suggested by Al Viro.
> > - Call exit_files() in coredump_wait(),
> >   as suggested by Eric W. Biederman.
> >   Add MMF_DUMP_MAPPED_SHARED mm_flags_test() check to filter cases that
> >   need to dump file-backed shared memory.
> > 
> > v1:
> > - Link to v1: https://lore.kernel.org/all/20260618030700.2511668-1-jackzxcui1989@163.com/
> > ---
> >  fs/coredump.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/fs/coredump.c b/fs/coredump.c
> > index bb6fdb1f4..e20baf44f 100644
> > --- a/fs/coredump.c
> > +++ b/fs/coredump.c
> > @@ -548,6 +548,9 @@ static int coredump_wait(int exit_code, struct core_state *core_state)
> >  		}
> >  	}
> >  
> > +	if (!mm_flags_test(MMF_DUMP_MAPPED_SHARED, tsk->mm))
> > +		exit_files(tsk);
> 
> Memory mapped files keep their own separate references to the files
> (in struct vm_area_struct::vm_file), so there is no need to attempt to
> work around this. Unless I'm misunderstanding what you're attempting
> to work around.

Waiit, I think I get it - you have a flock on a file, and you're scared
that if you unlock early, some other process can lock it and modify some other
file we have mapped? If so, that does make some sense. Please add that as
a comment and/or into the git log, because it feels very much non-obvious
to me.

-- 
Pedro

  reply	other threads:[~2026-06-18 17:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18 15:03 [PATCH v2] coredump: exit_files() in coredump_wait() if MMF_DUMP_MAPPED_SHARED is not set Xin Zhao
2026-06-18 16:07 ` Pedro Falcato
2026-06-18 17:19   ` Pedro Falcato [this message]
2026-06-19  0:39     ` 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=ajQoFeTyIqh6tMVv@pedro-suse \
    --to=pfalcato@suse.de \
    --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 \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox