> On Aug 23, 2018, at 5:31 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > >> On Thu, Aug 23, 2018 at 05:16:53PM -0700, Andy Lutomirski wrote: >>> On Thu, Aug 23, 2018 at 5:08 PM, David Howells <dhowells@xxxxxxxxxx> wrote: >>> Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>> >>>> Has anything been done to ensure that the behavior when doing >>>> FSCONFIG_CMD_CREATE against an already-mounted block device is >>>> reasonable? >>> >>> For the moment, I've left it as the same behaviour as for mount(2) since >>> mount(2) now uses the same mechanism internally and we aren't permitted to >>> break userspace. >>> >>> I would like to add at least one flag to stipulate that, in the case of an >>> incompatible collision, you can get a failure - but defining what is meant by >>> incompatible isn't necessarily trivial, and would vary by filesystem *and* the >>> LSM. >>> >>> However, I don't want to start reengineering everything this close to the >>> merge window and we don't really need it immediately. >>> >> >> The problem is that, once this ends up merged, then we're kind of >> stuck with it, too. It would be a bit sad if your better proposal for >> handling nfs and instantiation of filesystems in general were added in >> the next release and then we end up with the current >> FSCONFIG_CMD_CREATE as a permanently supported but non-preferred >> option. > > For fuck sake, mount(2) is a permanently supported option! Exactly. mount(2) has broken semantics and it’s permanently supported. If this merge request gets pulled, then FSCONFIG_CMD_CREATE will *also* be a permanently supported API with broken semantics.
