|Priority:||4 - Normal|
|Created by:||Patrick Mooney [X]|
|Reported by:||Patrick Mooney [X]|
|Assigned to:||Patrick Mooney [X]|
Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2015-05-22T16:21:06.000Z)
2015-05-28 PCjr (Release Date: 2015-05-28)
Code outside of vfs itself which accesses v_path has the potential to race if v_path is freed (due to an invalidation) while the accesser is holding the pointer. This was mostly safe, since v_path transitioned from non-NULL to NULL very infrequently. (It appears there was/is a narrow window during rename.)
To ensure accessers are completely safe, v_lock should be used to eliminate any race potential.
At the time of this writing, the following files have "dangerous" v_path usage:
fs/dev/sdev_subr.c fs/hyprlofs/hyprlofs_vnops.c fs/nfs/nfs4_srv.c fs/nfs/nfs4_srv_ns.c fs/nfs/nfs_server.c fs/smbsrv/smb_oplock.c fs/tmpfs/tmp_vnops.c fs/zfs/zfs_dir.c io/inotify.c io/vscan/vscan_svc.c
Additionally, there is logic in dtrace/dtrace.c which marks v_path as accessible memory to probes using getf. At this time, implementing that safely does not appear possible.