From: Andy Lutomirski <luto@amacapital.net>
To: Jeff Layton <jlayton@redhat.com>, linux-fsdevel@vger.kernel.org
Cc: nfs-ganesha-devel@lists.sourceforge.net,
samba-technical@lists.samba.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 13/14] locks: skip deadlock detection on FL_FILE_PVT locks
Date: Thu, 09 Jan 2014 12:25:25 -0800 [thread overview]
Message-ID: <52CF05B5.5080700@amacapital.net> (raw)
In-Reply-To: <1389277187-18211-14-git-send-email-jlayton@redhat.com>
On 01/09/2014 06:19 AM, Jeff Layton wrote:
> It's not really feasible to do deadlock detection with FL_FILE_PVT
> locks since they aren't owned by a single task, per-se. Deadlock
> detection also tends to be rather expensive so just skip it for
> these sorts of locks.
I just looked at the existing deadlock detector, and... eww.
When I think of deadlocks caused by r/w locks (which these are), I think
of two kinds. First is what the current code tries to detect: two
processes that are each waiting for each other. I don't know whether
POSIX enshrines the idea of detecting that, but I wouldn't be surprised,
considering how awful the old POSIX locks are.
The sensible kind of detectable deadlock involves just one lock, and it
happens when two processes both hold read locks and try to upgrade to
write locks. This should be efficiently detectable and makes upgrading
locks safe(r).
I think I'd be happier if it's at least documented that the new fcntl
calls might (some day) detect that kind of deadlock.
All that being said, this patch series is awesome. I've lost count of
the number of explosions I've seen to due POSIX lock crap. Thanks!
--Andy
next prev parent reply other threads:[~2014-01-09 20:25 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 14:19 [PATCH v5 00/14] locks: implement "file-private" (aka UNPOSIX) locks Jeff Layton
2014-01-09 14:19 ` [PATCH v5 01/14] locks: close potential race between setlease and open Jeff Layton
2014-01-09 14:19 ` [PATCH v5 02/14] locks: clean up comment typo Jeff Layton
2014-01-09 14:19 ` [PATCH v5 03/14] locks: remove "inline" qualifier from fl_link manipulation functions Jeff Layton
2014-01-09 14:19 ` [PATCH v5 04/14] locks: add __acquires and __releases annotations to locks_start and locks_stop Jeff Layton
2014-01-09 14:19 ` [PATCH v5 05/14] locks: eliminate BUG() call when there's an unexpected lock on file close Jeff Layton
2014-01-09 14:19 ` [PATCH v5 06/14] locks: fix posix lock range overflow handling Jeff Layton
2014-01-09 14:19 ` [PATCH v5 07/14] locks: consolidate checks for compatible filp->f_mode values in setlk handlers Jeff Layton
2014-01-09 14:19 ` [PATCH v5 08/14] MAINTAINERS: add Bruce and myself to list of maintainers for file locking code Jeff Layton
2014-01-09 14:19 ` [PATCH v5 09/14] locks: rename locks_remove_flock to locks_remove_file Jeff Layton
2014-01-09 14:19 ` [PATCH v5 10/14] locks: make /proc/locks show IS_FILE_PVT locks with a P suffix Jeff Layton
2014-01-09 14:19 ` [PATCH v5 11/14] locks: report l_pid as -1 for FL_FILE_PVT locks Jeff Layton
2014-01-09 14:19 ` [PATCH v5 12/14] locks: pass the cmd value to fcntl_getlk/getlk64 Jeff Layton
2014-01-09 14:19 ` [PATCH v5 13/14] locks: skip deadlock detection on FL_FILE_PVT locks Jeff Layton
2014-01-09 20:25 ` Andy Lutomirski [this message]
2014-01-10 0:49 ` Jeff Layton
2014-01-10 0:58 ` Andy Lutomirski
2014-01-14 19:27 ` J. Bruce Fields
2014-01-14 20:29 ` Andy Lutomirski
2014-01-14 21:10 ` J. Bruce Fields
2014-01-14 21:17 ` Andy Lutomirski
2014-01-14 21:25 ` J. Bruce Fields
2014-01-14 21:18 ` Jeff Layton
2014-01-14 21:19 ` Frank Filz
2014-01-14 21:24 ` Andy Lutomirski
2014-01-14 21:26 ` Andy Lutomirski
2014-01-14 21:34 ` Frank Filz
2014-01-14 21:51 ` J. Bruce Fields
2014-01-14 22:26 ` Andy Lutomirski
2014-01-14 21:26 ` J. Bruce Fields
[not found] ` <CALwJ=MyRRjL9kXMdQgACJ6GDTMoMzMJcckuvKk1NBqJD2G07pg@mail.gmail.com>
2014-01-14 21:24 ` Andy Lutomirski
2014-01-14 21:30 ` J. Bruce Fields
2014-01-09 14:19 ` [PATCH v5 14/14] locks: add new fcntl cmd values for handling file private locks Jeff Layton
2014-01-09 20:29 ` Andy Lutomirski
2014-01-10 0:55 ` Jeff Layton
2014-01-10 1:01 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52CF05B5.5080700@amacapital.net \
--to=luto@amacapital.net \
--cc=jlayton@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nfs-ganesha-devel@lists.sourceforge.net \
--cc=samba-technical@lists.samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox