- User Since
- Jun 4 2014, 10:38 AM (287 w, 2 d)
- remove shared lock assertion from vop_stdlock
- add a comment about new lockmgr primitives
- convert zfs. both tmpfs and zfs changes will be committed separately
With filtering support (D22690) this should not be needed
This change was supposed to be a stop gap before a more time consuming real solution is implemented. Given the feedback I decided to just go for it, see D22715
Thu, Dec 5
- tighten up the assertion
Given the complaint raised in D22689 I suggest the following.
If you are worried about catching code doing such an unlock, we can add an assertion to unlock that if VI_DOOMED is set, v_op is dead_vnodeops. If want such an unlock to remain legitimate, I can move v_iflag to the beginning of the struct. Right now there is a 4 byte hole in there on amd64 (after v_tag got moved). I did not want to do it because it adds an avoidable constraint on reshuffling of the layout for later.
Wed, Dec 4
I decided to go with a different approach. D22665
Tue, Dec 3
I don't have good basics to comment on the code itself, however the vnode is often already shared locked which I presume stabilizes the result. I suspect the code can be reworked to provide all the necessary guarantees with just the interlock. If not,
Sun, Dec 1
Sat, Nov 30
Wed, Nov 27
Looks like these guards should be __cplusplus instead?
- drop _lock.h and _mtx.h
- move the lock to cdev_privdata
Mon, Nov 25
- bump D_VERSION
- annotate the lock in witness
Wed, Nov 20
Sun, Nov 17
Sat, Nov 16
ping? the change passed tests by pho
I noted if /any/ acl denies execution, the newly added function fails. Then the caller is expected to fall back to the current code which will also perform an acl walk.
Nov 5 2019
The point was ACLs are always walked if needed which is not hard to verify and it answers the question.
Nov 4 2019
Setting ACLs performs the following:
Nov 3 2019
You can see the fast path is gated by ZFS_NO_EXECS_DENIED. Should anything be there to deny an exec to /someone/, fast path fails.