| Age | Commit message (Collapse) | Author |
|
Prune a whole lotta dead branches as a result of this. (Some logic
calling this is also wrong for other reasons; devsw_detach is final
-- you should never have any reason to decide to roll it back. To be
cleaned up in subsequent commits...)
XXX kernel ABI change to devsw_detach signature requires bump
|
|
Now that tun_lock runs at IPL_NONE, taking it does not have the side
effect of disabling preemption, but pktq_enqueue assumes the caller
has disabled preemption so it can safely schedule a softint.
This isn't a problem in most physical network drivers because the
pktq_enqueue call happens from within the driver's softint context
anyway. But tun(4) is special -- here, the pktq_enqueue is triggered
by a userland write to the device, which is in thread context. So
let's just disable preemption in tunwrite.
Reported-by: syzbot+21c2cb300f1ec2162b35@syzkaller.appspotmail.com
|
|
|
|
cv_broadcast aleady has a fast path for no-waiters.
|
|
Otherwise, tp->tun_pgid is not stable.
|
|
This is never taken from hardware interrupt handlers any more, as far
as I can tell -- only SOFTINT_NET soft interrupt handlers.
This avoids trying to take an adaptive lock, proc_lock, in fownsignal
while holding a spin lock. Unfortunately, it doesn't entirely fix the
problem -- proc_lock is at IPL_NONE, and is held across some not
entirely trivial computations like allocating a new pid table. So it
would really be better if we had some way to deliver SIGIO without
taking proc_lock.
Reported-by: syzbot+3dd54993d3e92e697e72@syzkaller.appspotmail.com
Reported-by: syzbot+aca29415f2f0bf23f082@syzkaller.appspotmail.com
|
|
This is always taken in process/thread context, never in interrupt
context, hard or soft.
|
|
- Reduce duplication.
- Plug softint leak on recycling tun.
(This recycling business seems kinda sketchy...)
|
|
|
|
|
|
define a flag FILTEROP_ISFD that has the meaning of the prior f_isfd.
Field and flag name aligned with OpenBSD.
This does not constitute a functional or ABI change, as the field location
and size, and the value placed in that field, are the same as the previous
code, but we're bumping __NetBSD_Version__ so 3rd-party module source code
can adapt, as needed.
NetBSD 9.99.89
|
|
|
|
This mirrors tap(4).
|
|
because the value can change in the meantime (and get set to zero).
|
|
Reported-by: syzbot+45b31355bf880e175b73@syzkaller.appspotmail.com
|
|
|
|
Found by a custom query on LGTM.
|
|
It really doesn't make that much difference to the code, but the output
from modstat(8) is different! (With an empty string in the MODULE() macro
modstat reports an empty string, but with a NULL in the macro, modstat
prints a '-' just like it does for other "empty" fields.)
|
|
|
|
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.
|
|
|
|
|
|
Remove the zombie unit from the zombie list, not the regular list!
|
|
already been removed from the list in the find_zunit() code.
So now, off to really find out why the module won't unload.
|
|
|
|
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.
|
|
These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
|
|
filt_tunread gets called in two contexts:
- by calls to selnotify in if_tun.c (or knote, as the case may be,
but not here), in which case tp->tun_lock is held; and
- by internal logic in kevent, in which tp->tun_lock is not held.
The standard convention to discriminate between these two cases is by
setting the kernel-only NOTE_SUBMIT bit in the hint to selnotify or
knote; then in filt_*:
if (hint & NOTE_SUBMIT)
KASSERT(mutex_owned(&tp->tun_lock));
else
mutex_enter(&tp->tun_lock);
...
if (hint & NOTE_SUBMIT)
KASSERT(mutex_owned(&tp->tun_lock));
else
mutex_exit(&tp->tun_lock);
Pointed out by and patch from riastradh@
Tested by ozaki-r@ (only the former path)
|
|
filt_tunread is called with tun_lock held from tun_output (via tun_output =>
selnotify => knote), so we must not take tun_lock in filt_tunread. The bug
is triggered only if a tun is used through kqueue.
Found by k-goda@IIJ
|
|
compatibility with BIOC[GS]SEESENT ioctl. The userland interface is the same
as FreeBSD.
This change also fixes a bug that the direction is misunderstand on some
environment by passing the direction to bpf_mtap*() instead of checking
m->m_pkthdr.rcvif.
|
|
Calls to pfil_run_hooks() were missing in if_tun.c. This meant that
filtering configuration could be added to e.g. /etc/npf.conf, but
would be ignored, because the filter never saw the packets. This
change adds the required calls.
While here, correct the return value from tun_output(): it's been
returning 0 regardless of any error condition present, but will now
correctly propagate such information upward.
Thanks to maxv for guidance!
OK: christos, martin
|
|
completes
And ensure to turn off it before destruction as per IFF_RUNNING's description
"resource allocated". (The description is a bit doubtful though, I believe the
change is still proper.)
|
|
if_link_state_change
|
|
Mostly done with spatch with touchups for indentation
@@
expression a;
identifier b,c,d;
identifier p;
@@
const struct filterops p =
- { a, b, c, d
+ {
+ .f_isfd = a,
+ .f_attach = b,
+ .f_detach = c,
+ .f_event = d,
};
|
|
to deallocate the containing memory chunk (the tunnel's softc). Otherwise
a LOCKDEBUG kernel will panic in tun_clone_destroy().
Fixes PR kern/52255
|
|
so don't mutex_exit(tun_lock) in them, but only in
the one that needs it.
ok skrll
|
|
|
|
Mostly from rmind-smpnet
|
|
|
|
|
|
|
|
Before the rearrangement of ifaddr initializations (in.c,v 1.169),
when we called tun_enable via ioctl(SIOCINITIFADDR), an ifaddr
in question was inserted in the interface address list. However,
after the change the ifaddr isn't in the list at that point. So
we shouldn't rely on that we can find the ifaddr by
IFADDR_READER_FOREACH. Instead simply use the ifaddr passed by
ioctl(SIOCINITIFADDR).
|
|
It should be more proper.
|
|
|
|
|
|
|
|
As usual, we leave the old list to avoid breaking kvm(3) users.
|
|
The API is used to set (or reset) a received interface of a mbuf.
They are counterpart of m_get_rcvif, which will come in another
commit, hide internal of rcvif operation, and reduce the diff of
the upcoming change.
No functional change.
|
|
We no longer need to change rtentry below if_output.
The change makes it clear where rtentries are changed (or not)
and helps forthcoming locking (os psrefing) rtentries.
|
|
|