On Tue, 18 Sep 2007, J. Bruce Fields wrote:
On Tue, Sep 18, 2007 at 12:54:56PM -0400, Trond Myklebust wrote:
It gets even better when you throw mmap() into the mix :-)
Hm. Documentation/mandatory.txt claims that it mandatory locks and
mmap() with MAP_SHARED exclude each other, but I
On Tue, Sep 18, 2007 at 10:36:32AM +0400, Pavel Emelyanov wrote:
J. Bruce Fields wrote:
I would also prefer a locking scheme that didn't rely on the BKL. That
said, except for this race:
I would as well :) But I don't know the locking code good enough to
start fixing. Besides, even if I
On Wed, 2007-09-19 at 14:07 -0400, J. Bruce Fields wrote:
On Tue, Sep 18, 2007 at 10:36:32AM +0400, Pavel Emelyanov wrote:
J. Bruce Fields wrote:
I would also prefer a locking scheme that didn't rely on the BKL. That
said, except for this race:
I would as well :) But I don't know
J. Bruce Fields wrote:
On Mon, Sep 17, 2007 at 10:37:56AM +0400, Pavel Emelyanov wrote:
J. Bruce Fields wrote:
Is there a small chance that a lock may be applied after this check:
+ mandatory = (inode-i_flock MANDATORY_LOCK(inode));
+
but early enough that someone can still block on the
Trond Myklebust wrote:
On Mon, 2007-09-17 at 18:16 +0400, Pavel Emelyanov wrote:
Trond Myklebust wrote:
On Mon, 2007-09-17 at 12:13 +0400, Pavel Emelyanov wrote:
When the process is blocked on mandatory lock and someone changes
the inode's permissions, so that the lock is no longer
On Tue, Sep 18, 2007 at 10:33:26AM +0400, Pavel Emelyanov wrote:
Trond Myklebust wrote:
IOW: the process that is waiting in locks_mandatory_area() will be
released as soon as the advisory lock is dropped. If that theory is
broken in practice, then that is the bug that we need to fix. We
On Tue, Sep 18, 2007 at 12:14:55PM -0400, Trond Myklebust wrote:
Note also that strictly speaking, we're not even compliant with the
System V behaviour on read() and write(). See:
http://www.unix.org.ua/orelly/networking_2ndEd/nfs/ch11_01.htm
and
On Tue, 2007-09-18 at 12:52 -0400, J. Bruce Fields wrote:
On Tue, Sep 18, 2007 at 12:14:55PM -0400, Trond Myklebust wrote:
Note also that strictly speaking, we're not even compliant with the
System V behaviour on read() and write(). See:
On Tue, Sep 18, 2007 at 12:54:56PM -0400, Trond Myklebust wrote:
On Tue, 2007-09-18 at 12:52 -0400, J. Bruce Fields wrote:
So currently there's nothing to prevent this:
- write passes locks_mandatory_area() checks
- get mandatory lock
- read old data
J. Bruce Fields wrote:
On Thu, Sep 13, 2007 at 06:30:43PM +0400, Pavel Emelyanov wrote:
When the process is blocked on mandatory lock and someone changes
the inode's permissions, so that the lock is no longer mandatory,
nobody wakes up the blocked process, but probably should.
I suppose so.
On Mon, 2007-09-17 at 12:13 +0400, Pavel Emelyanov wrote:
When the process is blocked on mandatory lock and someone changes
the inode's permissions, so that the lock is no longer mandatory,
nobody wakes up the blocked process, but probably should.
Please explain in more detail why we need
Trond Myklebust wrote:
On Mon, 2007-09-17 at 12:13 +0400, Pavel Emelyanov wrote:
When the process is blocked on mandatory lock and someone changes
the inode's permissions, so that the lock is no longer mandatory,
nobody wakes up the blocked process, but probably should.
Please explain in
On Mon, Sep 17, 2007 at 10:37:56AM +0400, Pavel Emelyanov wrote:
J. Bruce Fields wrote:
Is there a small chance that a lock may be applied after this check:
+ mandatory = (inode-i_flock MANDATORY_LOCK(inode));
+
but early enough that someone can still block on the lock while the
On Mon, 2007-09-17 at 18:16 +0400, Pavel Emelyanov wrote:
Trond Myklebust wrote:
On Mon, 2007-09-17 at 12:13 +0400, Pavel Emelyanov wrote:
When the process is blocked on mandatory lock and someone changes
the inode's permissions, so that the lock is no longer mandatory,
nobody wakes up
14 matches
Mail list logo
