From: David Howells <firstname.lastname@example.org>
To: Andrei Vagin <email@example.com>
Cc: firstname.lastname@example.org, Andrei Vagin <email@example.com>,
firstname.lastname@example.org, Andrei Vagin <email@example.com>
Subject: Re: [PATCH dhowells/mount-context] fs: don't call fs_context->free() from fsmount()
Date: Wed, 01 Aug 2018 01:42:29 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
Andrei Vagin <email@example.com> wrote:
> > > Does it mean that fc->fs_type->init_fs_context() should not be called
> > > contexts which are created from fspick()?
> > No. I've put a flag in the context that is set when ->init_fs_context() is
> > called and cleared when ->free() is called. ->free() isn't called in the put
> > routine if the flag isn't set.
> > /* We've done the mount bit - now move the file context into
> > * more or less the same state as if we'd done an fspick().
> According to this comment, a context after fsmount() should be in
> the same state as after fspick().
> In fsmount(), we call ->free() which is oposite to init_fs_context(). If
> we want to have "more or less the same state" and want to call
> fs_context->free() in fsmount(), this means that we should not call
> fc->fs_type->init_fs_context() in fspick()... Where am I wrong?
vfs_fsconfig() calls ->init_fs_context() if fc->phase is
FS_CONTEXT_AWAITING_RECONF. This is so that we don't actually fully reinit
the context unnecessarily if the fd is just going to be closed after fsmount()
fspick() assumes that you're definitely going to reconfigure the superblock
(presumably that's why you used it) and always reinitialises the context,
shoving fc->phase round to FS_CONTEXT_RECONF_PARAMS.
next prev parent reply other threads:[~2018-08-01 2:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-31 7:29 [PATCH dhowells/mount-context] fs: don't call fs_context->free() from fsmount() Andrei Vagin
2018-07-31 8:52 ` David Howells
2018-07-31 17:34 ` Andrei Vagin
2018-07-31 20:56 ` David Howells
2018-07-31 22:48 ` Andrei Vagin
2018-08-01 0:42 ` David Howells [this message]
2018-08-01 5:53 ` Andrei Vagin
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).