mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Chris Wright <chrisw@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Make POSIX locks compatible with the NPTL thread model
Date: Wed, 23 Jun 2004 15:50:10 -0400	[thread overview]
Message-ID: <1088020210.5806.95.camel@lade.trondhjem.org> (raw)
In-Reply-To: <20040623122930.K22989@build.pdx.osdl.net>

På on , 23/06/2004 klokka 15:29, skreiv Chris Wright:
> Just ran some quick tests to verify this patch still works fine with
> execve() after plain CLONE_FILES as well as full CLONE_THREAD.  Passed
> my tests.  Nice to see the steal_locks bit go.  However, without this
> patch (only the prior one, I'm getting an oops).

Can you show us the Oops? I'm surprised that should be occurring...

Note that with both patches, we still have some problems in the locking
downcall interface to the filesystem. Currently there exists an
atomicity problem: after the call to ->lock() there is a window during
which the filesystem believes that a lock may have been taken/released
but the VFS has not yet registered this fact. In 2.4.x, this window did
not exist because the VFS held the BKL from beginning to end.

As far as NFS is concerned, this makes use of the VFS in order to
recover from server reboots (which is in fact the only reason why we
bother to have the VFS track the locking) buggy...

IMHO, NFS/CIFS/... should just call posix_lock_file() directly from
their ->lock() method. That way they will also be able to full take
responsibility for protecting the call.

Cheers,
  Trond

  reply	other threads:[~2004-06-23 19:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-23 17:07 Trond Myklebust
2004-06-23 19:29 ` Chris Wright
2004-06-23 19:50   ` Trond Myklebust [this message]
2004-06-23 21:41     ` Chris Wright
2004-06-23 23:02       ` Trond Myklebust
2004-06-24  6:09         ` Chris Wright
2004-06-24 11:56 ` Andreas Gruenbacher
2004-06-24 21:06   ` Trond Myklebust

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=1088020210.5806.95.camel@lade.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=akpm@osdl.org \
    --cc=chrisw@osdl.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®