On Wed, Aug 01, 2018 at 01:42:29AM +0100, David Howells wrote: > Andrei Vagin <avagin@xxxxxxxxxxxxx> 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() > is called. I understood the idea. Thank you for the explanation. > > 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. > > David
