[Bug 198085] service devfs restart leaks tap devices

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198085

            Bug ID: 198085
           Summary: service devfs restart leaks tap devices
           Product: Base System
           Version: 10.1-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: brian at shadowcom.net

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 at tokyo:~ # ls /dev/tap* | wc
     198     198    2266
root at tokyo:~ # service devfs restart
root at 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 at tokyo:~ # head /etc/jail.conf
pdc1 {
        mount.devfs;
        devfs_ruleset = 5;
...

root at tokyo:~ # cat /etc/devfs.rules
[devfsrules_pdc1=5]
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 at tokyo:~ # service jail start pdc1
Starting jails: pdc1.
root at 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 at 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. :)

-- 
You are receiving this mail because:
You are the assignee for the bug.