On Tue, 21 Apr 2009, Ruslan Ermilov wrote:
Is it possible I am running into some of the interface lock fixes rwatson
has been working on ? This box has a lot of ng interfaces which come and
go. Perhaps snmp asking about an interface that just went away caused the
panic ? I disabled bsnmp since the reboot and the box has been up for 10hrs
so far.
It's a documented bug:
Just to follow up on this thread: I've committed a work-around to 7-STABLE as
well as the 7.2 release engineering branch. The on-going ifnet
reference-counting/address list locking/etc work in 8-CURRENT is the long-term
solution, and I will MFC it after 7.2 is out the door and it's settled some,
but with any luck the work-around will prevent instant panics in the described
scenario.
Robert N M Watson
Computer Laboratory
University of Cambridge
: revision 1.281
: date: 2008/06/26 23:05:28; author: rwatson; state: Exp; lines: +69 -12
: SVN rev 180042 on 2008-06-26 23:05:28Z by rwatson
:
: Introduce locking around use of ifindex_table, whose use was previously
: unsynchronized. While races were extremely rare, we've now had a
: couple of reports of panics in environments involving large numbers of
: IPSEC tunnels being added very quickly on an active system.
:
: - Add accessor functions ifnet_byindex(), ifaddr_byindex(),
: ifdev_byindex() to replace existing accessor macros. These functions
: now acquire the ifnet lock before derefencing the table.
: - Add IFNET_WLOCK_ASSERT().
: - Add static accessor functions ifnet_setbyindex(), ifdev_setbyindex(),
: which set values in the table either asserting of acquiring the ifnet
: lock.
: - Use accessor functions throughout if.c to modify and read
: ifindex_table.
: - Rework ifnet attach/detach to lock around ifindex_table modification.
:
: Note that these changes simply close races around use of ifindex_table,
: and make no attempt to solve the probem of disappearing ifnets. Further
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: refinement of this work, including with respect to ifindex_table
: resizing, is still required.
:
: In a future change, the ifnet lock should be converted from a mutex to an
: rwlock in order to reduce contention.
:
: Reviewed and tested by: brooks
Cheers,
--
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"