VOP_VPUT_PAIR(): handle the case when dvp == vp
AcceptedPublic
Actions

Authored by kib on Wed, Jun 24, 6:23 PM.

Details

Reviewers

jah
markj
mckusick

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

kib created this revision.Wed, Jun 24, 6:23 PM

Herald added a subscriber: imp. · View Herald TranscriptWed, Jun 24, 6:23 PM

kib requested review of this revision.Wed, Jun 24, 6:23 PM

Also handle in the default implementation

Herald added a subscriber: olce. · View Herald TranscriptWed, Jun 24, 6:34 PM

markj added inline comments.Wed, Jun 24, 8:28 PM

sys/ufs/ffs/ffs_vnops.c
2012	Don't you also need to check here?

Is there some situation in which we expect dvp and vp to be the same, without the caller taking steps to avoid using VOP_VPUT_PAIR() in the first place?

In D57824#1325771, @jah wrote:

Is there some situation in which we expect dvp and vp to be the same, without the caller taking steps to avoid using VOP_VPUT_PAIR() in the first place?

I hope that no, there is no such case. I wanted to use VOP_VPUT_PAIR() in some path for the RENAME_EXCHANGE path but it requires more generic behavior.

Handle one more return place for dvp == vp.

markj added inline comments.Thu, Jun 25, 7:02 PM

sys/kern/vfs_default.c
1633–1634	What should the VOP do if `unlock_vp` is false and `vp == dvp`? Right now we're unconditionally unlocking it.

Clean up the case dvp == vp && !unlock_vp.
Add comment to vop_stdvput_pair() explaining the intent.
Change vrele() to vunref() for locked vnode, but it should be nop since there must be one more use reference.

jah accepted this revision.Thu, Jun 25, 11:19 PM

This revision is now accepted and ready to land.Thu, Jun 25, 11:19 PM

markj added inline comments.Fri, Jun 26, 2:04 PM