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
On Wed, 11 Sep 2002, Bruce Evans wrote:
> 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
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 Pr
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
>>
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
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 l
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 asse
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 a
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
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
>>> >
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 e
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
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
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 everythin
> 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. Co
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
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 c
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!
> */
> VOP
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,
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);
T
20 matches
Mail list logo