On Mar 6, 2014, at 13:41, Dr Fields James Bruce <bfields@xxxxxxxxxxxx> wrote: > On Tue, Mar 04, 2014 at 06:50:10PM -0500, Trond Myklebust wrote: >> >> On Mar 4, 2014, at 17:56, Dr Fields James Bruce <bfields@xxxxxxxxxxxx> wrote: >> >>> On Tue, Mar 04, 2014 at 05:42:31PM -0500, Trond Myklebust wrote: >>>> On Mar 4, 2014, at 16:14, Dr Fields James Bruce <bfields@xxxxxxxxxxxx> >>>> wrote: >>>>> Good point: if I understand it right, in the mandatory locking case, >>>>> before doing a read or write we first check if we'd be able to apply >>>>> a classic posix lock. And that lock will always conflict with a >>>>> file-private lock. >>>>> >>>>> I think we should just not worry about it and see if anyone >>>>> complains. File-private locks are a new feature and I don't see >>>>> that we're under any obligation to support the combination of >>>>> file-private locks and mandatory locking. >>>>> >>>>> Mandatory locking is already buggy (because of the race between >>>>> checking for locks and performing the IO). If we get no complaints >>>>> about this file-private behavior then that's more evidence we could >>>>> use to justify just ripping it out completely some day.... >>> ... >>>> The problem is that mandatory locking is something the administrator >>>> and user enable. It isn’t entirely under the control of the >>>> application… If you write a program that uses file-private locks, I >>>> can trivially DOS it by manipulating the mount parameters and >>>> manipulating the file's group execute and sgid bit. >>> >>> Or you could take a lock on the file and DOS it in the same way. >>> >>> Why isn't the answer "don't do that”? >> >> …because as a rule, it is bloody non-obvious and neither you nor Jeff had >> thought of it? > > Agreed that it certainly violates the principal of least surprise. > > I just don't think that maintaining Linux's mandatory locking is worth > any unnecessary effort. Nobody should be using it anyway as far as I > can tell. If you can convince Linus to take a patch that disables the ‘-omand’ mount option, then that’s fine too, however leaving a known implementation bug is not... _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- 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
