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

From: David Howells
Date: Wed May 03 2017 - 14:41:56 EST

Jeff Layton <jlayton@xxxxxxxxxxxxxxx> 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.