summaryrefslogtreecommitdiffstats
path: root/usr.bin/tmux/tmux.h
diff options
context:
space:
mode:
authorbeck <beck@openbsd.org>2009-12-17 16:30:45 +0000
committerbeck <beck@openbsd.org>2009-12-17 16:30:45 +0000
commitd4d95a55b98940749a0aceb91c2b7b820979dea0 (patch)
tree2315c30dc8411e22b73e5b1b473ce02b1c47a720 /usr.bin/tmux/tmux.h
parentbe slightly more paranoid about shell stuff we run. (diff)
downloadwireguard-openbsd-d4d95a55b98940749a0aceb91c2b7b820979dea0.tar.xz
wireguard-openbsd-d4d95a55b98940749a0aceb91c2b7b820979dea0.zip
This fixes a case where we could panic on a null deref with a bad vnode
in nfs_inactive, on a reboot. The core of the problem was in nfs_nget, when we lose the race to put a new nfsnode in the tree, we have previously allocated a vnode, which getnewvnode has done an insmntque into the nfs mp's mntlist. The problem being we then try again with a new vnode, abandoning this one on the mntlist, leaving junk there for us to die on when we unmount. This introduces VLARVAL - so we can indicate in a vnode that the higher level stuff hiding in v_data is incompletely set up. This flag is then used by nfs to deal with a halfway set up vnode and release it correctly. analysis and bogus fix by art@, correct fix by me after serveral failed attempts and much painful testing by krw@, good suggestions by tedu and miod ok krw@ oga@ thib@ blambert@ art@
Diffstat (limited to 'usr.bin/tmux/tmux.h')
0 files changed, 0 insertions, 0 deletions