This slightly simplifies some upcoming unionfs work.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 56189 Build 53077: arc lint + arc unit
Event Timeline
I have some forthcoming unionfs work that (at least in its current implementation) uses vn_lock_pair() in a helper function that takes the locking flags as parameters, and in which the second vnode may be NULL. In general it seems odd that, even when a vnode is NULL, the caller still needs to pass some contrived lock flags for it to appease the assert.
Specifically, 0, which would seem like a sensible default if there is no corresponding vnode to lock, will not work due to the SHARED^EXCLUSIVE assert.
Sure, we could do that, but I'm curious: is there some reason why we should care what the lockflags are if there is no vnode to lock? What I have here seems more straightforward than making specific allowances for NULL vnodes.
I am about the reliable checking for the API contracts. Assume that some function calls vn_lock_pair() with externally-specified flags, and corresponding vp could be NULL sometimes. I want such calls to always have correct flags, esp. if vp != NULL is rare or could not be easily checked by normal testing.