linux-kernel - Re: [PATCH v5 13/14] locks: skip deadlock detection on FL_FILE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52CF05B5.5080700@amacapital.net>
Date:	Thu, 09 Jan 2014 12:25:25 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Jeff Layton <jlayton@...hat.com>, linux-fsdevel@...r.kernel.org
CC:	nfs-ganesha-devel@...ts.sourceforge.net,
	samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 13/14] locks: skip deadlock detection on FL_FILE_PVT
 locks

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/