On Wed, Nov 11, 2015 at 11:49:20AM -0600, Eric W. Biederman wrote: > > Mandatory locking appears to be almost unused and buggy and there > appears no real interest in doing anything with it. Since effectively > no one uses the code and since the code is buggy let's allow it to be > disabled at compile time. I would just suggest removing the code but > undoubtedly that will break some piece of userspace code somewhere. > > For the distributions that don't care about this piece of code > this gives a nice starting point to make mandatory locking go away. > > Cc: Benjamin Coddington <bcodding@xxxxxxxxxx> > Cc: Dmitry Vyukov <dvyukov@xxxxxxxxxx> > Cc: Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx> > Cc: J. Bruce Fields <bfields@xxxxxxxxxxxx> > Signed-off-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx> > --- > > A piece of userspace software having problematic interactions with > mandatory locking recently came up as an issue Is there any more interesting story there? > and I am wondering if there are enough people actually using and > interested in mandatory locking that it makes sense to push people to > support it, or if mandatory locking should be confined to it's own > little corner of existence where it can wither and die. I hate mandatory locking and would be delighted, but my opinion probably shouldn't get too much weight. > From what little I can glean we want to discourage people from using > mandatory locking and to let it wither and die. A Kconfig option that > allows mandatory locking to be disabled at compile time seems like the > first step in making that happen. Perhaps in a decade or so when all > linux distributions are setting the option we can remove the code. > > Does anyone know of any real world use cases of mandatory locking? Isn't byte-range locking on Windows mandatory? So Samba people might be the ones to talk to. (Or Wine? Or anyone else doing Windows interoperability.) My suspicion would be that the semantics they need are different enough from what we support that we'd be better off ignoring it and starting over from scratch anyway. But I could be wrong. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
