History log of /freebsd/sys/net/if_tuntap.c (Results 26 – 50 of 55)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/11.4.0
# 75dfc66c 27-Feb-2020 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r358269 through r358399.


# 7029da5c 26-Feb-2020 Pawel Biernacki <kaktus@FreeBSD.org>

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly mark

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.

This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.

Mark all obvious cases as MPSAFE. All entries that haven't been marked
as MPSAFE before are by default marked as NEEDGIANT

Approved by: kib (mentor, blanket)
Commented by: kib, gallatin, melifaro
Differential Revision: https://reviews.freebsd.org/D23718

show more ...


# 051669e8 25-Jan-2020 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r356931 through r357118.


# af614b8e 23-Jan-2020 Gleb Smirnoff <glebius@FreeBSD.org>

tap(4) calls ether_input() in context of write(2). Enter network
epoch here.

The tun(4) side doesn't need this, as netisr code will take care.


Revision tags: release/12.1.0
# f7810883 23-Oct-2019 Kyle Evans <kevans@FreeBSD.org>

tuntap(4): Fix NOINET build after r353741

Shuffle headers around to more appropriate #ifdef OPTION blocks (INET vs.
INET6) -- double checked LINT-{NOINET,NOINET6,NOIP}, all seem good.

Reported by:

tuntap(4): Fix NOINET build after r353741

Shuffle headers around to more appropriate #ifdef OPTION blocks (INET vs.
INET6) -- double checked LINT-{NOINET,NOINET6,NOIP}, all seem good.

Reported by: cem

show more ...


# 200abb43 22-Oct-2019 Kyle Evans <kevans@FreeBSD.org>

tuntap(4): properly declare if_tun and if_tap modules

Simply adding MODULE_VERSION does not do the trick, because the modules
haven't been declared. This should actually fix modfind/kldstat, which
r

tuntap(4): properly declare if_tun and if_tap modules

Simply adding MODULE_VERSION does not do the trick, because the modules
haven't been declared. This should actually fix modfind/kldstat, which
r351229 aimed and failed to do.

This should make vm-bhyve do the right thing again when using the ports
version, rather than the latest version not in ports.

MFC after: 3 days

show more ...


# 3d501333 21-Oct-2019 Kyle Evans <kevans@FreeBSD.org>

tuntap(4): restrict scope of net.link.tap.user_open slightly

net.link.tap.user_open has historically allowed non-root users to do devfs
cloning and open /dev/tap* nodes based on permissions. Loosen

tuntap(4): restrict scope of net.link.tap.user_open slightly

net.link.tap.user_open has historically allowed non-root users to do devfs
cloning and open /dev/tap* nodes based on permissions. Loosen this up to
make it only allow users to do devfs cloning -- we no longer check it in
tunopen.

This allows tap devices to be created that can actually be opened by a user,
rather than swiftly restricting them to root because the magic sysctl has
not been set.

The sysctl has not yet been completely deprecated, because more thought is
needed for how to handle the devfs cloning case. There is not an easy
suitable replacement for the sysctl there, and more care needs to be placed
in determining whether that's OK or not.

PR: 200185

show more ...


# 60250777 21-Oct-2019 Kyle Evans <kevans@FreeBSD.org>

tuntap(4): use cdevpriv w/ dtor for last close instead of d_close

cdevpriv dtors will be called when the reference count on the associated
struct file drops to 0, while d_close can be unreliable for

tuntap(4): use cdevpriv w/ dtor for last close instead of d_close

cdevpriv dtors will be called when the reference count on the associated
struct file drops to 0, while d_close can be unreliable for cleaning up
state at "last close" for a number of reasons. As far as tunclose/tundtor is
concerned the difference is minimal, so make the switch.

show more ...


# 6869d530 21-Oct-2019 Kyle Evans <kevans@FreeBSD.org>

tuntap(4): Use make_dev_s to avoid si_drv1 race

This allows us to avoid some dance in tunopen for dealing with the
possibility of dev->si_drv1 being NULL as it's set prior to the devfs node
being cr

tuntap(4): Use make_dev_s to avoid si_drv1 race

This allows us to avoid some dance in tunopen for dealing with the
possibility of dev->si_drv1 being NULL as it's set prior to the devfs node
being created in all cases.

There's still the possibility that the tun device hasn't been fully
initialized, since that's done after the devfs node was created. Alleviate
this by returning ENXIO if we're not to that point of tuncreate yet.

This work is what sparked r353128, full initialization of cloned devices
w/ specified make_dev_args.

show more ...


# 486c0b22 20-Oct-2019 Kyle Evans <kevans@FreeBSD.org>

tuntap(4): break out after setting TUN_DSTADDR

This is now the only flag we set in this loop, terminate early.


# 6041d76e 20-Oct-2019 Kyle Evans <kevans@FreeBSD.org>

tuntap(4): Drop TUN_IASET

This flag appears to have been effectively unused since introduction to
if_tun(4) -- drop it now.


# f8bc74e2 18-Oct-2019 Vincenzo Maffione <vmaffione@FreeBSD.org>

tap: add support for virtio-net offloads

This patch is part of an effort to make bhyve networking (in particular TCP)
faster. The key strategy to enhance TCP throughput is to let the whole packet
da

tap: add support for virtio-net offloads

This patch is part of an effort to make bhyve networking (in particular TCP)
faster. The key strategy to enhance TCP throughput is to let the whole packet
datapath work with TSO/LRO packets (up to 64KB each), so that the per-packet
overhead is amortized over a large number of bytes.
This capability is supported in the guest by means of the vtnet(4) driver,
which is able to handle TSO/LRO packets leveraging the virtio-net header
(see struct virtio_net_hdr and struct virtio_net_hdr_mrg_rxbuf).
A bhyve VM exchanges packets with the host through a network backend,
which can be vale(4) or if_tap(4).
While vale(4) supports TSO/LRO packets, if_tap(4) does not.
This patch extends if_tap(4) with the ability to understand the virtio-net
header, so that a tapX interface can process TSO/LRO packets.
A couple of ioctl commands have been added to configure and probe the
virtio-net header. Once the virtio-net header is set, the tapX interface
acquires all the IFCAP capabilities necessary for TSO/LRO.

Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D21263

show more ...


# 73c96bbe 11-Oct-2019 Gleb Smirnoff <glebius@FreeBSD.org>

Don't use if_maddr_rlock() in tuntap(4), use epoch(9) directly instead.


# 8b3bc70a 08-Oct-2019 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r352764 through r353315.


# b8a6e03f 08-Oct-2019 Gleb Smirnoff <glebius@FreeBSD.org>

Widen NET_EPOCH coverage.

When epoch(9) was introduced to network stack, it was basically
dropped in place of existing locking, which was mutexes and
rwlocks. For the sake of performance mutex cover

Widen NET_EPOCH coverage.

When epoch(9) was introduced to network stack, it was basically
dropped in place of existing locking, which was mutexes and
rwlocks. For the sake of performance mutex covered areas were
as small as possible, so became epoch covered areas.

However, epoch doesn't introduce any contention, it just delays
memory reclaim. So, there is no point to minimise epoch covered
areas in sense of performance. Meanwhile entering/exiting epoch
also has non-zero CPU usage, so doing this less often is a win.

Not the least is also code maintainability. In the new paradigm
we can assume that at any stage of processing a packet, we are
inside network epoch. This makes coding both input and output
path way easier.

On output path we already enter epoch quite early - in the
ip_output(), in the ip6_output().

This patch does the same for the input path. All ISR processing,
network related callouts, other ways of packet injection to the
network stack shall be performed in net_epoch. Any leaf function
that walks network configuration now asserts epoch.

Tricky part is configuration code paths - ioctls, sysctls. They
also call into leaf functions, so some need to be changed.

This patch would introduce more epoch recursions (see EPOCH_TRACE)
than we had before. They will be cleaned up separately, as several
of them aren't trivial. Note, that unlike a lock recursion the
epoch recursion is safe and just wastes a bit of resources.

Reviewed by: gallatin, hselasky, cy, adrian, kristof
Differential Revision: https://reviews.freebsd.org/D19111

show more ...


# 29128766 04-Oct-2019 Kyle Evans <kevans@FreeBSD.org>

tuntap(4): loosen up tunclose restrictions

Realistically, this cannot work. We don't allow the tun to be opened twice,
so it must be done via fd passing, fork, dup, some mechanism like these.
Applic

tuntap(4): loosen up tunclose restrictions

Realistically, this cannot work. We don't allow the tun to be opened twice,
so it must be done via fd passing, fork, dup, some mechanism like these.
Applications demonstrably do not enforce strict ordering when they're
handing off tun devices, so the parent closing before the child will easily
leave the tun/tap device in a bad state where it can't be destroyed and a
confused user because they did nothing wrong.

Concede that we can't leave the tun/tap device in this kind of state because
of software not playing the TUNSIFPID game, but it is still good to find and
fix this kind of thing to keep ifconfig(8) up-to-date and help ensure good
discipline in tun handling.

MFC after: 3 days

show more ...


# 59997c3c 03-Oct-2019 Kyle Evans <kevans@FreeBSD.org>

if_tuntap: create /dev aliases when a tuntap device gets renamed

Currently, if you do:

$ ifconfig tun0 create
$ ifconfig tun0 name wg0
$ ls -l /dev | egrep 'wg|tun'

You will see tun0, but no wg0.

if_tuntap: create /dev aliases when a tuntap device gets renamed

Currently, if you do:

$ ifconfig tun0 create
$ ifconfig tun0 name wg0
$ ls -l /dev | egrep 'wg|tun'

You will see tun0, but no wg0. In fact, it's slightly more annoying to make
the association between the new name and the old name in order to open the
device (if it hadn't been opened during the rename).

Register an eventhandler for ifnet_arrival_events and catch interface
renames. We can determine if the ifnet is a tun easily enough from the
if_dname, which matches the cevsw.d_name from the associated tuntap_driver.

Some locking dance is required because renames don't require the device to
be opened, so it could go away in the middle of handling the ioctl, but as
soon as we've verified this isn't the case we can attempt to busy the tun
and either bail out if the tun device is dying, or we can proceed with the
rename.

We only create these aliases on a best-effort basis. Renaming a tun device
to "usbctl", which doesn't exist as an ifnet but does as a /dev, is clearly
not that disastrous, but we can't and won't create a /dev for that.

show more ...


# c4cad154 03-Oct-2019 Kyle Evans <kevans@FreeBSD.org>

if_tuntap: add a busy/unbusy mechanism, replace destroy OPEN check

A future commit will create device aliases when a tuntap device is renamed
so that it's still easily found in /dev after the rename

if_tuntap: add a busy/unbusy mechanism, replace destroy OPEN check

A future commit will create device aliases when a tuntap device is renamed
so that it's still easily found in /dev after the rename. Said mechanism
will want to keep the tun alive long enough to either realize that it's
about to go away or complete the alias creation, even if the alias is about
to get destroyed.

While we're introducing it, using it to prevent open devices from going away
makes plenty of sense and keeps the logic on waking up tun_destroy clean, so
we don't have multiple places trying to cv_broadcast unless it's still in
use elsewhere.

show more ...


# 5c4eed86 19-Aug-2019 Kyle Evans <kevans@FreeBSD.org>

tuntap: belatedly add MODULE_VERSION for if_tun and if_tap

When tun/tap were merged, appropriate MODULE_VERSION should have been added
for things like modfind(2) to continue to do the right thing wi

tuntap: belatedly add MODULE_VERSION for if_tun and if_tap

When tun/tap were merged, appropriate MODULE_VERSION should have been added
for things like modfind(2) to continue to do the right thing with the old
names.

Reported by: jhb

show more ...


# b5b83671 19-Aug-2019 Vincenzo Maffione <vmaffione@FreeBSD.org>

if_tuntap: minor improvements

Rewrite a loop to avoid duplicating the exit condition.
Simplify mask processing in tunpoll().
Fix minor typos.

Reviewed by: kevans, markj
MFC after: 2 weeks
Different

if_tuntap: minor improvements

Rewrite a loop to avoid duplicating the exit condition.
Simplify mask processing in tunpoll().
Fix minor typos.

Reviewed by: kevans, markj
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D21302

show more ...


# a63915c2 28-Jul-2019 Alan Somers <asomers@FreeBSD.org>

MFHead @r350386

Sponsored by: The FreeBSD Foundation


# 0dbac71f 26-Jul-2019 Kyle Evans <kevans@FreeBSD.org>

if_tuntap(4): Add TUNGIFNAME

This effectively just moves TAPGIFNAME into common ioctl territory.

MFC after: 3 days


Revision tags: release/11.3.0
# 0269ae4c 06-Jun-2019 Alan Somers <asomers@FreeBSD.org>

MFHead @348740

Sponsored by: The FreeBSD Foundation


# e2e050c8 20-May-2019 Conrad Meyer <cem@FreeBSD.org>

Extract eventfilter declarations to sys/_eventfilter.h

This allows replacing "sys/eventfilter.h" includes with "sys/_eventfilter.h"
in other header files (e.g., sys/{bus,conf,cpu}.h) and reduces hea

Extract eventfilter declarations to sys/_eventfilter.h

This allows replacing "sys/eventfilter.h" includes with "sys/_eventfilter.h"
in other header files (e.g., sys/{bus,conf,cpu}.h) and reduces header
pollution substantially.

EVENTHANDLER_DECLARE and EVENTHANDLER_LIST_DECLAREs were moved out of .c
files into appropriate headers (e.g., sys/proc.h, powernv/opal.h).

As a side effect of reduced header pollution, many .c files and headers no
longer contain needed definitions. The remainder of the patch addresses
adding appropriate includes to fix those files.

LOCK_DEBUG and LOCK_FILE_LINE_ARG are moved to sys/_lock.h, as required by
sys/mutex.h since r326106 (but silently protected by header pollution prior
to this change).

No functional change (intended). Of course, any out of tree modules that
relied on header pollution for sys/eventhandler.h, sys/lock.h, or
sys/mutex.h inclusion need to be fixed. __FreeBSD_version has been bumped.

show more ...


# db226f0d 14-May-2019 Kyle Evans <kevans@FreeBSD.org>

tuntap: Defer clearing if_softc until after if_detach

r346670 added an sx to close a race between the ifioctl handler and
interface destruction. Unfortunately, it clears if_softc immediately after
t

tuntap: Defer clearing if_softc until after if_detach

r346670 added an sx to close a race between the ifioctl handler and
interface destruction. Unfortunately, it clears if_softc immediately after
the interface is closed, but before if_detach has been invoked.

Any time before detachment, an interface that's part of a bridge may still
receive traffic that's pushed through tunstart/tunstart_l2 and promptly
lead to a panic because if_softc is now NULL.

Fix it by deferring the clearing of if_softc until after the interface has
detached and thus been removed from the bridge. if_softc still gets cleared
in case another thread has already entered the ioctl handler before it's
replaced with ifdead_ioctl.

Reported by: markj
MFC after: 3 days

show more ...


123