The locking changes in union_link() need a thorough review,
though the light testing of that I performed didn't turn up any
glaring problems.
The changes are obviously just cleanups for leaf file systems, but I
wonder why everything wasn't always locked at the top.
On 10 Sep, Bruce Evans wrote:
The locking changes in union_link() need a thorough review,
though the light testing of that I performed didn't turn up any
glaring problems.
The changes are obviously just cleanups for leaf file systems, but I
wonder why everything wasn't
On Tue, 10 Sep 2002, Don Lewis wrote:
On 10 Sep, Bruce Evans wrote:
The locking changes in union_link() need a thorough review,
though the light testing of that I performed didn't turn up any
glaring problems.
The changes are obviously just cleanups for leaf file
On 10 Sep, Bruce Evans wrote:
On Tue, 10 Sep 2002, Don Lewis wrote:
On 10 Sep, Bruce Evans wrote:
The changes are obviously just cleanups for leaf file systems, but I
wonder why everything wasn't always locked at the top. Could it have
been because locking all the way down is harmful?
Bruce Evans wrote:
The changes are obviously just cleanups for leaf file systems, but I
wonder why everything wasn't always locked at the top. Could it have
been because locking all the way down is harmful?
For a stacked local media FS, you can end up with a deadlock, if
a lower vnode is
On 10 Sep, Don Lewis wrote:
On 10 Sep, Bruce Evans wrote:
On Tue, 10 Sep 2002, Don Lewis wrote:
On 10 Sep, Bruce Evans wrote:
The changes are obviously just cleanups for leaf file systems, but I
wonder why everything wasn't always locked at the top. Could it have
been because
On 10 Sep, Terry Lambert wrote:
Bruce Evans wrote:
The changes are obviously just cleanups for leaf file systems, but I
wonder why everything wasn't always locked at the top. Could it have
been because locking all the way down is harmful?
For a stacked local media FS, you can end up with
On Tue, 10 Sep 2002, Don Lewis wrote:
The changes are obviously just cleanups for leaf file systems, but I
wonder why everything wasn't always locked at the top. Could it have
been because locking all the way down is harmful?
I think this is because some places are still worrying
On Tue, 10 Sep 2002, Don Lewis wrote:
I have just one thing to add to Robert's reply.
BTW, is it safe to call ASSERT_VOP_UNLOCKED() in the SMP case after the
reference has been dropped with vput() or vrele()?
I think it is. It has some internal locking (v_interlock at least), and
only
On 11 Sep, Bruce Evans wrote:
On Tue, 10 Sep 2002, Don Lewis wrote:
I have just one thing to add to Robert's reply.
BTW, is it safe to call ASSERT_VOP_UNLOCKED() in the SMP case after the
reference has been dropped with vput() or vrele()?
I think it is. It has some internal locking
On Tue, 10 Sep 2002, Don Lewis wrote:
On 11 Sep, Bruce Evans wrote:
On Tue, 10 Sep 2002, Don Lewis wrote:
I have just one thing to add to Robert's reply.
BTW, is it safe to call ASSERT_VOP_UNLOCKED() in the SMP case after the
reference has been dropped with vput() or vrele()?
On 10 Sep, Robert Watson wrote:
On Tue, 10 Sep 2002, Don Lewis wrote:
I'm mostly worried about the vnode being recycled as something else
after the vput() or vrele() call. I think a better approach would be to
add the assertion checks to vput() and vrele(), which would mean that we
could
On Tue, 10 Sep 2002, Robert Watson wrote:
... Also, last time I tried to use the ddb
show lockedvnods command, I got the problem attached below due to locking
issues, which makes it a lot harder to debug locking problems...
Robert N M Watson FreeBSD Core Team, TrustedBSD
On 9 Sep, Don Lewis wrote:
On 9 Sep, Robert Watson wrote:
What I'd actually like to do is lock vp on going in to the VOP. I need to
grab the lock in the link() code anyway to do the MAC check. UFS and
others all immediately lock the vnode on entry anyway...
Here's a patch to
nfs_link() contains the following code:
/*
* Push all writes to the server, so that the attribute cache
* doesn't get out of sync with the server.
* XXX There should be a better way!
*/
VOP_FSYNC(vp, cnp-cn_cred, MNT_WAIT, cnp-cn_thread);
The
On 9 Sep, Don Lewis wrote:
nfs_link() contains the following code:
/*
* Push all writes to the server, so that the attribute cache
* doesn't get out of sync with the server.
* XXX There should be a better way!
*/
VOP_FSYNC(vp,
On Mon, 9 Sep 2002, Don Lewis wrote:
nfs_link() contains the following code:
/*
* Push all writes to the server, so that the attribute cache
* doesn't get out of sync with the server.
* XXX There should be a better way!
*/
On 9 Sep, Robert Watson wrote:
On Mon, 9 Sep 2002, Don Lewis wrote:
I think we can probably just lock and unlock vp around the call to
VOP_FSYNC() ...
What I'd actually like to do is lock vp on going in to the VOP. I need to
grab the lock in the link() code anyway to do the MAC check.
On 9 Sep, Robert Watson wrote:
What I'd actually like to do is lock vp on going in to the VOP. I need to
grab the lock in the link() code anyway to do the MAC check. UFS and
others all immediately lock the vnode on entry anyway...
Here's a patch to implement this. It compiles and seems
19 matches
Mail list logo
