kernel: Move semicolon from the definition of SYSINIT() to its invocations. This affected around 70 of our (more or less) 270 SYSINIT() calls. style(9) advocates the terminating semicolon to be supplied by the invocation too, because it can make life easier for editors and other source code parsing programs.
kernel - Performance tuning (3) * The VOP_CLOSE issues revealed a bigger issue with vn_lock(). Many callers do not check the return code for vn_lock() and in nearly all of those cases it wouldn't fail anyway due to a prior ref, but it creates an API issue. * Add the LK_FAILRECLAIM flag to vn_lock(). This flag explicitly allows vn_lock() to fail if the vnode is undergoing reclamation. This fixes numerous issues, particularly when VOP_CLOSE() is called during a reclaim due to recent LK_UPGRADE's that we do in some VFS *_close() functions. * Remove some unused LK_ defines.
kernel - proc_token removal pass stage 1/2 * Remove proc_token use from all subsystems except kern/kern_proc.c. * The token had become mostly useless in these subsystems now that process locking is more fine-grained. Do the final wipe of proc_token except for allproc/zombproc list use in kern_proc.c
kernel - Attempt to fix tty race * Opening /dev/tty is special cased to open the session ttyvp. The VCTTYISOPEN flag is used on the session ttyvp to indicate this. * There is a bug where the VCTTYISOPEN flag is set prior to calling VOP_OPEN() on ttyvp. Because devfs's devfs_spec_open() (and also devfs_spec_close()) temporarily release the vnode lock on the vp (ttyvp in this case), setting the flag prior to the VOP_OPEN() can lead to a race where another process opens AND closes /dev/tty before our VOP_OPEN() executes. The racing open will see that the VCTTYISOPEN flag is already set and not issue a VOP_OPEN(). It's close will then VOP_CLOSE() ttyvp (which so far has not been opened by either process), which can kill the last open on ttyvp and cause the tty to disconnect. This race is very difficult to reproduce. We were only able to reproduce it on monster (48-core opteron) which happened to access "/dev/tty" during a poudriere bulk build in a manner that was able to trigger the race. * Fix this particular bug by not setting the VCTTYISOPEN flag until after VOP_OPEN() returns, then re-checking the flag to detect the race and clean-up/retry if a race is detected. * TODO - This is not the only bug. Unfortunately it is also quite possible for multiple threads/processes to open("/dev/tty", ...) simultaniously. There is only one VCTTYISOPEN flag so when this occurs and one process then close()s its descriptor, the VCTTYISOPEN flag is cleared. The other process or processes may then proceed to access ttyvp without an opencount guard. When they close() the count is handled properly because the close() code detects that the VCTTYISOPEN flag was cleared. The problem is the unguarded read, write, and ioctl calls that might occur in the mean time.
kernel - Major signal path adjustments to fix races, tsleep race fixes, +more * Refactor the signal code to properly hold the lp->lwp_token. In particular the ksignal() and lwp_signotify() paths. * The tsleep() path must also hold lp->lwp_token to properly handle lp->lwp_stat states and interlocks. * Refactor the timeout code in tsleep() to ensure that endtsleep() is only called from the proper context, and fix races between endtsleep() and lwkt_switch(). * Rename proc->p_flag to proc->p_flags * Rename lwp->lwp_flag to lwp->lwp_flags * Add lwp->lwp_mpflags and move flags which require atomic ops (are adjusted when not the current thread) to the new field. * Add td->td_mpflags and move flags which require atomic ops (are adjusted when not the current thread) to the new field. * Add some freeze testing code to the x86-64 trap code (default disabled).
kernel - Hold required token when accessing p_flags, adjust kmem access * Numerous adjustments to p->p_flag were not being done with p->p_token held. In particular uiomove(). * Replace P_DEADLKTREAT with LWP_DEADLKTREAT in several places where it had not been previously converted. * Allow DMAP access in is_globaldata_space() for x86-64
MPSAFE - TTY & related drivers * Put kern/tty_* under the tty_token (and acquire the proc_token where needed). * MPSAFE all related drivers (users of kbdsw, linesw and vidsw) with the same tty_token. * NOTE: syscons.c and scvgarndr.c are not really under this new lock yet as some really strange hangs appear. Some are related to the cursor drawing (which stalls the machine if a token is held) and others are in some other syscons.c functions.
kernel - Make filters able to be marked MPSAFE * Change struct filterops f_isfd field to f_flags, taking FILTEROP_ISFD and/or FILTEROP_MPSAFE. * Convert all existing filter definitions to use new flags. * Create filter_attach/detach/event wrapper functions for calling through the struct filterops vector that grab the MPLOCK as necessary. * kern_event() uses kq->kq_count to determine whether or not to sleep, kqueue_scan() removes events from the TAILQ and can possibly sleep, releasing the global kq token, before updating kq->kq_count.
kernel - Fix kqfilter error return codes * Some kqfilters returned an Exxx error, others return 1 on error, and the device kq code returned -1 on error. * All kqfilters now return a proper Exxx error. * When an EVFILT is not implemented, EOPNOTSUPP is now returned. EPERM is no longer returned.