OS-4317: v_path accesses can race

Details

Issue Type:Bug
Priority:4 - Normal
Status:Resolved
Created at:2015-05-19T15:40:03.000Z
Updated at:2015-05-22T16:21:06.000Z

People

Created by:Patrick Mooney [X]
Reported by:Patrick Mooney [X]
Assigned to:Patrick Mooney [X]

Resolution

Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2015-05-22T16:21:06.000Z)

Fix Versions

2015-05-28 PCjr (Release Date: 2015-05-28)

Description

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.

Comments

Comment by Bot Bot [X]
Created at 2015-05-21T14:32:42.000Z

illumos-joyent commit 9066c32 (branch master, by Patrick Mooney)

OS-4317 v_path accesses can race
Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>