Date: Tue, 9 Nov 2004 19:02:21 +0300 (MSK) From: Vladimir Ivanov <wawa@yandex-team.ru> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/73719: Page fault in bpf_mtap () Message-ID: <200411091602.iA9G2L7B088186@sakura-vlan3.yandex.net> Resent-Message-ID: <200411091610.iA9GAOBK082782@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 73719
>Category: kern
>Synopsis: Page fault in bpf_mtap ()
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Nov 09 16:10:24 GMT 2004
>Closed-Date:
>Last-Modified:
>Originator: Charlie &
>Release: FreeBSD 5.3-STABLE i386
>Organization:
Yandex LLC
>Environment:
System: FreeBSD sakura.yandex.net 5.3-STABLE FreeBSD 5.3-STABLE #12: Thu Nov 4 22:02:05 MSK 2004 root@sakura.yandex.net:/usr/obj/usr/src/sys/SAKURA i386
>Description:
Sometimes FreeBSD router panics in bpf_mtap(). I can note that we are using bfps (with tcpdump e.g.) often on this PC.
sakura:/var/crash# kgdb -c vmcore.1 /boot/kernel/kernel
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
(no debugging symbols found)...0xc04f3da9 in doadump ()
(kgdb) bt
#0 0xc04f3da9 in doadump ()
#1 0xc04f44a6 in boot ()
#2 0xc04f4854 in panic ()
#3 0xc062a951 in trap_fatal ()
#4 0xc062a648 in trap_pfault ()
#5 0xc062a22d in trap ()
#6 0xc0616c2a in calltrap ()
#7 0xc55f0018 in ?? ()
#8 0xc22e0010 in ?? ()
#9 0xe4a90010 in ?? ()
#10 0xc275b802 in ?? ()
#11 0xc1f85800 in ?? ()
#12 0xe4a98c44 in ?? ()
#13 0xe4a98c10 in ?? ()
#14 0x00000800 in ?? ()
#15 0x00000040 in ?? ()
#16 0x000005ea in ?? ()
#17 0x00000000 in ?? ()
#18 0x0000000c in ?? ()
#19 0x00000000 in ?? ()
#20 0xc0568bcc in bpf_mtap ()
#21 0xc056fafd in ether_input ()
#22 0xc0480cd1 in em_process_receive_interrupts ()
#23 0xc047d9ff in em_intr ()
#24 0xc04dc01f in ithread_loop ()
#25 0xc04dadb3 in fork_exit ()
#26 0xc0616c8c in fork_trampoline ()
>How-To-Repeat:
Frequent opening/closing of bpf device should be enough I think to reproduce the problem.
>Fix:
We suppose that the problem is caused by unlocked modification of if_bpf pointer.
So, the suspicious place may be fixed by following patch:
--- bpf.h.orig Sun May 30 21:03:48 2004
+++ bpf.h Tue Nov 9 18:37:52 2004
@@ -473,9 +473,10 @@
bpf_tap((_ifp)->if_bpf, (_pkt), (_pktlen)); \
} while (0)
#define BPF_MTAP(_ifp,_m) do { \
- if ((_ifp)->if_bpf) { \
- M_ASSERTVALID(_m); \
- bpf_mtap((_ifp)->if_bpf, (_m)); \
+ struct bpf_if* bbb = (_ifp)->if_bpf; \
+ if (bbb) { \
+ M_ASSERTVALID(_m); \
+ bpf_mtap(bbb, (_m)); \
} \
} while (0)
#define BPF_MTAP2(_ifp,_data,_dlen,_m) do { \
>Release-Note:
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411091602.iA9G2L7B088186>