Bug 143621 - [ipfw] [dummynet] [patch] dummynet and vnet use results in panic
Summary: [ipfw] [dummynet] [patch] dummynet and vnet use results in panic
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 1.0-CURRENT
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-07 00:10 UTC by Gleb Kurtsou
Modified: 2020-07-11 16:30 UTC (History)
2 users (show)

See Also:

Attachments
file.diff (2.45 KB, patch)
2010-02-07 00:10 UTC, Gleb Kurtsou 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Gleb Kurtsou 2010-02-07 00:10:01 UTC 
dummynet doesn't set current vnet in its taskqueue thread (dummynet_send).

Patch is against recent 8-STABLE, but the same problem appears in CURRENT (although patch needs to be applied by hand). Fix is also tested on layer2 traffic.

Bactrace:

#0  doadump () at pcpu.h:223
223	pcpu.h: No such file or directory.
	in pcpu.h
(kgdb) #0  doadump () at pcpu.h:223
#1  0xffffffff802cef25 in boot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:416
#2  0xffffffff802cf3c9 in panic (fmt=Variable "fmt" is not available.
)
    at /usr/src/sys/kern/kern_shutdown.c:579
#3  0xffffffff804b7e73 in trap_fatal (frame=0xc, eva=Variable "eva" is not available.
)
    at /usr/src/sys/amd64/amd64/trap.c:857
#4  0xffffffff804b81d5 in trap_pfault (frame=0xffffff80001778a0, usermode=0)
    at /usr/src/sys/amd64/amd64/trap.c:773
#5  0xffffffff804b8a49 in trap (frame=0xffffff80001778a0)
    at /usr/src/sys/amd64/amd64/trap.c:499
#6  0xffffffff8049f943 in calltrap ()
    at /usr/src/sys/amd64/amd64/exception.S:224
#7  0xffffffff803885b6 in rt_tables_get_rnh (table=0, fam=2)
    at /usr/src/sys/net/route.c:151
#8  0xffffffff803889ff in rtalloc1_fib (dst=0xffffff8000177ad0, report=1, 
    ignflags=0, fibnum=Variable "fibnum" is not available.
) at /usr/src/sys/net/route.c:342
#9  0xffffffff8038a440 in rtalloc_ign_fib (ro=0xffffff8000177ac0, ignore=0, 
    fibnum=0) at /usr/src/sys/net/route.c:310
#10 0xffffffff803aec09 in ip_output (m=0xffffff0001305100, opt=Variable "opt" is not available.
)
    at /usr/src/sys/netinet/ip_output.c:269
#11 0xffffffff80c2324f in dummynet_send (m=0xffffff0001305100)
    at /usr/src/sys/modules/dummynet/../../netinet/ipfw/ip_dummynet.c:948
#12 0xffffffff80c2365f in dummynet_task (context=Variable "context" is not available.
)
    at /usr/src/sys/modules/dummynet/../../netinet/ipfw/ip_dummynet.c:930
#13 0xffffffff8030b01a in taskqueue_run (queue=0xffffff00017ba200)
    at /usr/src/sys/kern/subr_taskqueue.c:239
#14 0xffffffff8030b18c in taskqueue_thread_loop (arg=Variable "arg" is not available.
)
    at /usr/src/sys/kern/subr_taskqueue.c:360
#15 0xffffffff802a87aa in fork_exit (
    callout=0xffffffff8030b14d <taskqueue_thread_loop>, 
    arg=0xffffffff80c26e10, frame=0xffffff8000177c80)
    at /usr/src/sys/kern/kern_fork.c:843
#16 0xffffffff8049fd9e in fork_trampoline ()
    at /usr/src/sys/amd64/amd64/exception.S:561

Fix: Patch attached with submission follows:
How-To-Repeat: 
ipfw pipe config 100  bw 10kb
ipfw add 100 pipe 100 ip from any to any

Generate some traffic. Panics instantly
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2010-02-07 05:33:05 UTC 
Responsible Changed
From-To: freebsd-bugs->freebsd-ipfw

Patch is actually against ipfw, so over to that mailing list, although 
perhaps it should get to net@.
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:30 UTC 
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 3 Tom Jones freebsd_committer freebsd_triage 2020-07-11 16:19:26 UTC 
VNET was turn on by default in FreeBSD 12. If this issue still affects you please feel free to reopen.
Comment 4 Mark Johnston freebsd_committer freebsd_triage 2020-07-11 16:30:05 UTC 
To be clear, the dummynet task thread does run in a vnet as of r206461.  It sounds like additional work is still required to make dummynet vnet-aware.