Bug 198085 - service devfs restart leaks tap devices
Summary: service devfs restart leaks tap devices
Status: Closed Works As Intended
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.1-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Kyle Evans
Depends on:
Reported: 2015-02-27 21:51 UTC by brian
Modified: 2020-02-21 14:17 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description brian 2015-02-27 21:51:02 UTC
The /dev/tap* interface has become somewhat unstable as of 10.1-R; One particular problem is that every time I reload devfs (testing rulesets in a set of jails), the system creates a whole new set of tap interfaces.  For example:

root@tokyo:~ # ls /dev/tap* | wc
     198     198    2266
root@tokyo:~ # service devfs restart
root@tokyo:~ # ls /dev/tap* | wc
     205     205    2350

The other issue is with the "new" (to me) /dev/tap pre-interface that client utilities need to use to select and register a tap device.  This device doesn't consistently get created by devfs.rules in jailed environments, causing programs that depend on tap to fail on startup.

root@tokyo:~ # head /etc/jail.conf
pdc1 {
        devfs_ruleset = 5;

root@tokyo:~ # cat /etc/devfs.rules
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path 'tap' unhide mode 0600 group wheel
add path 'tap0' unhide mode 0600 group wheel
add path 'bridge0' unhide mode 0600 group wheel

root@tokyo:~ # service jail start pdc1
Starting jails: pdc1.
root@tokyo:~ # ls -l /jail/pdc1/dev/tap
ls: /jail/pdc1/dev/tap: No such file or directory

The device itself doesn't show up in directory listings, which can cause scripts that expect to "see" it to fail.  (I suspect this is also causing devfs.conf not to be able to correctly set permissions on this device.)

root@tokyo:~ # ls /dev/tap* | xargs echo | grep '/dev/tap '
(nothing returned)

If this interface is undergoing development, I'd understand these instabilities; If my system is missing configuration files that control this behavior, then my apologies.  Either way, would love to hear the development team's thoughts on this. :)
Comment 1 brian 2015-02-28 20:32:40 UTC
/dev/tap device "instability" may have been due to sysctl setting:

root@tokyo:/etc # ls -l /dev/tap
ls: /dev/tap: No such file or directory
root@tokyo:/etc # sysctl -a | grep net.link.tap.dev
net.link.tap.devfs_cloning: 0
root@tokyo:/etc # sysctl -w net.link.tap.devfs_cloning=1
root@tokyo:/etc # sysctl -a | grep net.link.tap.dev
net.link.tap.devfs_cloning: 1
root@tokyo:/etc # ls -l /dev/tap
crw-------  1 root  wheel  0xa9 Feb 28 15:30 /dev/tap

It is this sysctl that's making the /dev/tap* devices spawn too frequently, though.  (When set to zero, the "service devfs restart" command doesn't cause them to continue accumulating.)

Also still unable to see /dev/tap with a glob, but as long as the program (qemu-devel) can load it by explicit name, it's not the end of the world for me.
Comment 2 Kyle Evans freebsd_committer 2019-04-25 17:29:10 UTC

Taking, since I'm working on tun/tap. Is this still relevant in later FreeBSD versions? I can't seem to reproduce it (but also don't immediately see what might have fixed it), and will likely close this in two weeks as "overcome by events" unless I hear back.
Comment 3 Kyle Evans freebsd_committer 2020-02-21 14:17:48 UTC
The frequent spawning is indeed because of devfs cloning, any lookup of /dev/tap or any /dev/tapNN that doesn't exist will cause it to get created. You can cause two or three with a simple chmod 0777 /dev/tap, even.

devfs cloning in a jail can work, but it would require an unwritten MAC module to do so, IIRC. The canonical solution for this is to pre-create the tap device and unhide it in the jail.

Closing this with "Works As Intended" -- the cloning behavior isn't ideal, but it is expected and non-trivial to solve. devfs cloning in a jail should not be allowed without some consideration.