Re: [PATCH 4/9] Implement fsopen() to prepare for a mount

[David Howells <dhowells@redhat.com>]

Jeff Layton <jlayton@poochiereds.net> wrote:

> I think one of the neat things here is that we can now error out as
> soon as a bogus mount option is passed in.

It means that the 'sloppy' option can also now be implemented in userspace.

> > Once fsmount() has been called, further write() calls will incur EBUSY,
> > even if the fsmount() fails.  read() is still possible to retrieve error
> > information.
> > 
> 
> What's the rationale for the above behavior?
> 
> A failed attempt to graft it into the tree doesn't seem like it would
> have any real effect on the mount_context. While I can't think of a use
> case for being able to try fsmount() again, I don't quite understand
> why we'd prohibit someone from doing it.

The mount procedure is allowed to preallocate resources and attach them to the
mount context and ->mount() is allowed to use them up, say by transferring
them to the superblock.  The mount context is then in a degraded state and
cannot necessarily be reused.

David