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:	Sun, 27 May 2007 12:12:52 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	David Howells <dhowells@...hat.com>
Cc:	akpm@...l.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] AFS: Implement file locking

On Sun, May 27, 2007 at 09:51:10AM +0100, David Howells wrote:
> J. Bruce Fields <bfields@...ldses.org> wrote:
> > So if I request a write lock while holding a read lock, my request will
> > be denied?
> 
> At the moment, yes.  Don't the POSIX and flock lock-handling routines in the
> kernel normally do that anyway?

No, they'd upgrade in that case.

> > This is a little strange, though--if there's somebody waiting for a
> > write lock on an inode (because somebody else already holds a read lock
> > on it), that shouldn't block requests for read locks.
> 
> That depends on whether you want fairness or not.

Neither posix nor flock locks delay a lock because of pending
conflicting locks.  SUS, as I read it, wouldn't allow that.

> Allowing read locks to jump the queue like this can lead to starvation
> for your writers.

If you want fairness the best that you can do is to ensure that when
more than one pending lock can be applied, the one that has been waiting
longest will be chosen.  But you can't make all such lock requests wait
for a lock that hasn't even been applied yet.

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.  I
have no idea whether such applications actually exist in practice, but
I'd be uneasy about changing the standard behavior without inventing
some new kind of lock.

--b.
-
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/