illumos gate

This bug presented itself with /temp filesystem of some databases failing to mount. It turns out that mountd doesn't think the filesystem is in the sharetab, so it refuses to allow the remote system to mount it. The root cause of this issue appears to be a race condition. The sequence of events is as follows: T1 starts updating the sharetab, locking the sharetab lock, and opens /etc/dfs/sharetab. At that point, it has a snapshot of the sharetab, which will not change as new entries are added. Then another thread, the sharer, calls zfs_ioc_share (or, specifically, sharefs_impl) and adds the file to the sharetab. Then, the sharer exits kernel space, and prompts the remote mount attempt. Next, T2 in mountd calls check_sharetab, sees the mtime has changed since the last completed update, and enters the rwlock queue for the sharetab lock. Then, T1 gets the time again (for some reason? code is unclear, but this behavior doesn't affect the bug), updates the last time the mountd sharetab was updated, closes the file, and unlocks the lock. Then, T2 acquires the lock, sees that the last time the mountd sharetab was modified doesn't match its value from before it started grabbing the lock, and returns without doing anything. Finally, the mount request fails because the thread didn't update the sharetab when it should have.