Arp locking patches

Hi,

I was wondering if the arp locking patches (sys/netinet/if_ether.c 1.138-9 
and related changes) were planned to be MFC'd before 6.0 is released?  I'm 
seeing a panic on a dual CPU machine running BETA2/amd64 and am seeing the 
following panic semi-regularly which looks like it may be related to the 
lack of locking on the arp tables.

Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer         = 0x8:0xffffffff803f80da
stack pointer               = 0x10:0xffffffffb49c76f0
frame pointer               = 0x10:0xffffffffb49c7710
code segment                = base 0x0, limit 0xfffff, type 0x1b
                             = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags            = interrupt enabled, resume, IOPL = 0
current process             = 1073 (udp)
[thread pid 1073 tid 100100 ]
Stopped at      m_tag_delete_chain+0x2a:        movq    0(%rbx),%rsi
db>
db> tr
Tracing pid 1073 tid 100100 td 0xffffff0060ddebe0
m_tag_delete_chain() at m_tag_delete_chain+0x2a
mb_dtor_mbuf() at mb_dtor_mbuf+0x4d
uma_zfree_arg() at uma_zfree_arg+0x331
m_freem() at m_freem+0x41
arpresolve() at arpresolve+0x2f3
ether_output() at ether_output+0x23a
ip_output() at ip_output+0xb17
udp_send() at udp_send+0x42c
sosend() at sosend+0x654
soo_write() at soo_write+0x4d
dofilewrite() at dofilewrite+0x87
kern_writev() at kern_writev+0x51
write() at write+0x4a
syscall() at syscall+0x4b2
Xfast_syscall() at Xfast_syscall+0xa8
--- syscall (4, FreeBSD ELF64, write), rip = 0x80067c81c, rsp = 
0x7fffffffe4d8, rbp = 0x7fffffffe520 ---
db>

Note that the above was provoked with Peter Holm's stress test kit, but I 
have also had it on this machine in everyday use.  I'd be happy to test 
any patch.

Thanks,

Gavin



--
"Experience is directly proportional to the value of equipment destroyed."
                                                      -- Carolyn Scheppner
     - Gavin Atkinson  -  General layabout  -  University Radio York -