can be created by either 'ifconfig create' or 'open("/dev/tun0")' paths.
Note: previous efforts at fixing 'modunload if_tun' are abandoned, since
there is no bug. Just need to ensure that the cloned interface is both
close(1)d _and_ 'ifconfig tunx destroy' before trying to unload.
This address situations where dump(8) cannot figure out the device being
dumped. It also allows tracking of subvolume dumps by using virtual
device as dumpdates entry.
previously), remove it from the zombie list after freeing all of its
resources.
This should allow the module to be unloaded even if there was a zombie
at some point. Without this change, the zombie list never gets emptied.
If the user supplies a value for the attempted_completion_function parameter
then we cannot be sure if the completion is for filename or something else, in such
a case don't attempt to quote the completion matches.
Reviewed by christos
This should address PR lib/54067
before cpu_fsgs_reload() finishes, otherwise we write garbage in the GDT.
On NetBSD-current it is harmless, however in NetBSD-8 it might cause
panics, because NetBSD-8 uses the old SegRegs model and under this model
we reload %fs and %gs during switches.
pcb_flags to zero, and the moment cpu_segregs64_zero resets pcb_gs, we may
be preempted.
If this happens, and if the calling LWP was a 32bit thread, when switching
back to that LWP, the context switcher sees that PCB_COMPAT32 is not set in
pcb_flags and tries to perform a 64bit context switch; but pcb_gs contains
a 32bit GDT descriptor, and not a 64bit GS.base value. The wrmsr therefore
faults because the value is non-canonical, and this fault is fatal.
Rearrange the code so that the update of pcb_flags and pcb_gs/pcb_fs is non
interruptible. This fixes the problem, tested with a reproducer (which
therefore doesn't work anymore).
Likely fixes PR/53993.
The code was already modularized, we simply didn't build the loadable
module.
Note also that since the tap(4) device can be reasonably accessed by
either creating a device instance (using ifconfig(8)) or by opening
/dev/tap, we need to create both if_tap.kmod and tap.kmod (similar to
what is done with tun(4)).
depends, dependall, and all) rather than unconditionally
"building" it.
This avoids a "file exists" error from an update build
(where the objdir already contained the link to the file.)
ok mrg@ :
"if it works from a clean objdir, please commit it. we can fix more later.."
but it's very useful and costs basically nothing. I even think we could
enable it by default in the kernel (if we added __predict_false's and
removed some crap).
