Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process

[Trond Myklebust <trond.myklebust@primarydata.com>]

On Mar 4, 2014, at 17:56, Dr Fields James Bruce <bfields@fieldses.org> 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@fieldses.org>
>> 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?


_________________________________
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html