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. 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
