From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:32828 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732804AbeHACZY (ORCPT ); Tue, 31 Jul 2018 22:25:24 -0400 From: David Howells In-Reply-To: <20180731224807.GA8037@outlook.office365.com> References: <20180731224807.GA8037@outlook.office365.com> <20180731173421.GA14809@outlook.office365.com> <20180731072928.2413-1-avagin@openvz.org> <14901.1533027156@warthog.procyon.org.uk> <22269.1533070605@warthog.procyon.org.uk> To: Andrei Vagin Cc: dhowells@redhat.com, Andrei Vagin , linux-fsdevel@vger.kernel.org, Andrei Vagin Subject: Re: [PATCH dhowells/mount-context] fs: don't call fs_context->free() from fsmount() MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2699.1533084149.1@warthog.procyon.org.uk> Content-Transfer-Encoding: 8BIT Date: Wed, 01 Aug 2018 01:42:29 +0100 Message-ID: <2703.1533084149@warthog.procyon.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Andrei Vagin 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