K 10 svn:author V 3 avg K 8 svn:date V 27 2017-09-13T10:25:44.384537Z K 7 svn:log V 2055 8376 cached v_path should be kept fresh illumos/illumos-gate@e2fc3408efa6cdfc5e33c73c3567efc8c7592707 https://github.com/illumos/illumos-gate/commit/e2fc3408efa6cdfc5e33c73c3567efc8c7592707 https://www.illumos.org/issues/8376 The logic for generating and maintaining the cached v_path value on vnodes could stand to be improved. If vnodes were purely ephemeral, then freshly calculating v_path at the time of lookup() would result in correct values (at a performance cost). When they persist, either as referenced by other structures (such as open files, process cwd, dnlc entries, etc), the opportunity for the v_path to become stale arises. This is exacerbated by the current behavior that, when v_path is found to be invalid (during a vnodetopath operation) will strive to recalculate it, but not preserve the result. The overall situation leads to both performance and correctness (due to lack of results) problems relating to v_path. This has been addressed in SmartOS through a series of changes. Firstly, to do proper invalidation of v_path when it's found to be stale: - OS-3891 stale v_path slows vfs lookups OS-3891 revealed that some logic made assumptions about v_path never transitioning from non-NULL to NULL. It was addressed here: - OS-4317 v_path accesses can race While the pathological stale v_path behavior had been addressed, there are still cases where the absence of valid v_path information was causing problems. The largest patch in this series addressed it by performing v_path checking and updates during vnode lookups/updates, when it is most convenient: - OS-5167 cached v_path should be kept fresh Two smaller updates are included too, to prevent erroneous behavior introduced by the prior changes: - OS-5846 procfs should follow VFS rules - OS-6134 vn_reinit balks on zeroed vnodes Reviewed by: Jerry Jelinek Reviewed by: Robert Mustacchi Approved by: Gordon Ross Author: Patrick Mooney END