From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: [PATCH] locks: try to catch potential deadlock between file-private and classic locks from same process Date: Tue, 4 Mar 2014 18:50:10 -0500 Message-ID: References: <1393960249-18961-1-git-send-email-jlayton@redhat.com> <20140304193551.GG12805@fieldses.org> <20140304151451.07530a98@tlielax.poochiereds.net> <20140304153723.088db7cd@tlielax.poochiereds.net> <849B7F2D-A1C2-4E65-AE6A-0CCFA92990F0@primarydata.com> <20140304211443.GJ12805@fieldses.org> <2047AB7C-DE42-4FF8-A1BD-0F5CA33540BD@primarydata.com> <20140304225617.GK12805@fieldses.org> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Layton Jeff , Andy Lutomirski , Linux FS Devel To: Dr Fields James Bruce Return-path: Received: from mail-ig0-f171.google.com ([209.85.213.171]:35383 "EHLO mail-ig0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755523AbaCDXuO convert rfc822-to-8bit (ORCPT ); Tue, 4 Mar 2014 18:50:14 -0500 Received: by mail-ig0-f171.google.com with SMTP id hl1so9340675igb.4 for ; Tue, 04 Mar 2014 15:50:13 -0800 (PST) In-Reply-To: <20140304225617.GK12805@fieldses.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mar 4, 2014, at 17:56, Dr Fields James Bruce = 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 >> 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 appl= y >>> a classic posix lock. And that lock will always conflict with a >>> file-private lock. >>>=20 >>> 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. >>>=20 >>> 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=92t entirely under the control of the >> application=85 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. >=20 > Or you could take a lock on the file and DOS it in the same way. >=20 > Why isn't the answer "don't do that=94? =85because 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