Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752001AbaANVen (ORCPT ); Tue, 14 Jan 2014 16:34:43 -0500 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]:55361 "EHLO elasmtp-spurfowl.atl.sa.earthlink.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751503AbaANVek (ORCPT ); Tue, 14 Jan 2014 16:34:40 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fUjje2xUsGb7G0KZTF/etUVU75cTGXR9dGHTUEATpaUlZc2ouvWv8KSxdi3LKu8i; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-index:Content-language:X-Antivirus-Status:X-ELNK-Trace:X-Originating-IP; From: "Frank Filz" To: "'Andy Lutomirski'" Cc: "'J. Bruce Fields'" , "'Jeff Layton'" , "'Linux FS Devel'" , , , , "'Richard Hipp'" References: <1389277187-18211-1-git-send-email-jlayton@redhat.com> <1389277187-18211-14-git-send-email-jlayton@redhat.com> <52CF05B5.5080700@amacapital.net> <20140109194930.1692fbbe@tlielax.poochiereds.net> <20140114192713.GA22262@fieldses.org> <20140114211009.GA23999@fieldses.org> <039101cf116e$56c2de80$04489b80$@mindspring.com> In-Reply-To: Subject: RE: [PATCH v5 13/14] locks: skip deadlock detection on FL_FILE_PVT locks Date: Tue, 14 Jan 2014 13:34:25 -0800 Message-ID: <039201cf1170$668909a0$339b1ce0$@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-index: AQIxplNl3UwPk1McdlqVXO1PIZQSjgHxuHtVAik7TMsCB4kX9QHuwxiHAZAhYMwCAjlpFgHwcRUpAfMzOL0A2pM5hQEgQAERmTOCygA= Content-language: en-us X-Antivirus: avast! (VPS 140114-1, 01/14/2014), Outbound message X-Antivirus-Status: Clean X-ELNK-Trace: 136157f01908a8929c7f779228e2f6aeda0071232e20db4dc8c791b94e4d6357566b75ab51ca5d6c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.236.153.111 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > [grr, gmail -- I didn't actually intend to send that.] > > On Tue, Jan 14, 2014 at 1:24 PM, Andy Lutomirski > wrote: > > On Tue, Jan 14, 2014 at 1:19 PM, Frank Filz > wrote: > >>> process 2 requests a write lock, gets -EDEADLK, unlocks and > >>> requests a new read lock. That request succeeds because there > >>> is no conflicting lock. (Note the lock manager had no > >>> opportunity to upgrade 1's lock here thanks to the conflict with > >>> 3's lock.) > >> > >> As I understand write lock priority, process 2 requesting a new read > >> lock would block, once there is a write lock waiter, no further read > >> locks would be granted that would conflict with that waiting write lock. > > > > ...which reminds me -- if anyone implements writer priority, please > > make it optional (either w/ a writer-priority-ignoring read lock or a > > non-priority-granting write lock). I have an application for which > > writer priority would be really annoying. > > > > Even better: Have read-lock-and-wait-for-pending-writers be an explicit > new operation. > > > > (Writer priority a > > Writer priority can introduce new deadlocks. Suppose that a reader (holding > a read lock) starts a subprocess that takes a new read lock and waits for that > subprocess. Throw an unrelated process in that tries to take a write lock and > you have an instant deadlock. Hmm, that's an interesting one. With the new private locks, you could avoid that, because you can pass the read lock you already hold to that sub-process, such that the sub-process doesn't have to get it's own lock on the record in question. Frank -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/