linux-kernel - Re: [PATCH] AFS: Implement file locking

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]

Date:	Tue, 29 May 2007 10:34:41 +0100
From:	David Howells <dhowells@...hat.com>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	akpm@...l.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] AFS: Implement file locking

J. Bruce Fields <bfields@...ldses.org> wrote:

> You can contrive examples of applications that would be correct given
> the standard fcntl behavior, but that would deadlock on a system that
> didn't allow read locks to jump the queue in the above situation.

Yes, but you can also contrive starvation if you allow locks to jump the
queue.  Obviously, the Linux kernel behaviour is to allow readlocks to jump
the queue if a readlock is currently in force, so I have to conform to that,
whether I like it or not.

I'll need to test the upgrade/downgrade case.  I don't know whether the AFS
server supports that.  If it doesn't, I can emulate downgrade, but not upgrade
- not unless I only ever ask it for exclusive locks.

Lock upgrading is really, really easy to contrive deadlock for.

David
-
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/