On 15.11.2014 05:42, John-Mark Gurney wrote: > John-Mark Gurney wrote this message on Fri, Nov 14, 2014 at 11:39 > -0800: >> Well.. It looks like IPSEC is still broken in head... I can get >> pings to pass, but now on IPv4 transport mode, I can't get syn's >> to be sent out... I see the output packet in the protocol stats, >> but no packets go out the interface... >> >> If you could provide me w/ a simple set of spdadd commands, or the >> dumps from the machine, that'd be good... >> >> Hmm.... I just ran ping -f so I could generate some traffic, and >> managed to get a: panic: System call sendto returing with kernel >> FPU ctx leaked >> >> I'll look into this... > > I just verified that this happens on a clean HEAD @ r274534: FreeBSD > 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014 > [email protected]:/scratch/jmg/clean/sys/amd64/compile/IPSEC > amd64 > > No modifications, nothing, and I got the same panic: panic: System > call sendto returing with kernel FPU ctx leaked cpuid = 0 KDB: stack > backtrace: db_trace_self_wrapper() at > db_trace_self_wrapper+0x2b/frame 0xfffffe001de7a800 kdb_backtrace() > at kdb_backtrace+0x39/frame 0xfffffe001de7a8b0 vpanic() at > vpanic+0x189/frame 0xfffffe001de7a930 kassert_panic() at > kassert_panic+0x139/frame 0xfffffe001de7a9a0 amd64_syscall() at > amd64_syscall+0x616/frame 0xfffffe001de7aab0 Xfast_syscall() at > Xfast_syscall+0xfb/frame 0xfffffe001de7aab0 --- syscall (64, FreeBSD > ELF64, nosys), rip = 0x8011975aa, rsp = 0x7ffffffee588, rbp = > 0x7ffffffee5c0 --- KDB: enter: panic > > So, it's clearly not my patch that is causing the issue... > > Andrey, can you verify that you do not receive the same panic w/o my > patches?
11.0-CURRENT r274469
after 20 minutes and
# netstat -sp esp | grep out
424360710 packets out
17823149820 bytes out
can't reproduce the panic. I'll update and retry on fresh CURRENT.
My ipsec.conf:
add 10.9.12.25 10.9.12.15 esp 15701 -E rijndael-cbc "1111111111111111" ;
spdadd 192.168.0.0/16 192.168.0.0/16 any -P out ipsec
esp/tunnel/10.9.12.25-10.9.12.15/default;
aesni.ko is loaded and pmcstat shows that it is in use:
PMC: [INSTR_RETIRED_ANY] Samples: 128994 (100.0%) , 7506 unresolved
Key: q => exiting...
%SAMP IMAGE FUNCTION CALLERS
13.5 kernel cpu_search_highest cpu_search_highest:11.3
sched_idletd:2.2
4.6 kernel __mtx_unlock_flags ip_output:0.8 key_checkrequest:0.6
ip_rtaddr:0.6 key_allocsp:0.5
4.0 kernel __mtx_lock_flags _key_freesp:0.8 rtalloc1_fib:0.8
key_checkrequest:0.6
3.5 kernel cpu_search_lowest cpu_search_lowest:2.6
sched_pickcpu:0.9
3.2 kernel bcopy m_copydata:1.7 m_copyback:0.7
3.2 libc.so.7 bsearch
3.0 kernel __rw_rlock rtalloc1_fib
2.5 kernel uma_zalloc_arg malloc:0.8 crypto_getreq:0.6
2.4 kernel uma_zfree_arg m_freem:1.0 free:0.7
2.2 kernel bzero uma_zalloc_arg
2.1 kernel _rw_runlock_cookie rtalloc1_fib:0.7 arpresolve:0.5
2.0 kernel rn_match rtalloc1_fib
1.7 kernel __mtx_lock_sleep __mtx_lock_flags
1.7 kernel ip_output ipsec_process_done:1.1 ip_forward:0.6
1.4 kernel critical_exit spinlock_exit
1.3 kernel spinlock_exit ether_nh_input
1.3 kernel ixgbe_rxeof ixgbe_msix_que
1.2 kernel malloc
1.2 kernel critical_enter
1.2 kernel ixgbe_xmit ixgbe_mq_start_locked
1.1 aesni.ko aesni_encrypt_cbc aesni_process
1.1 kernel esp_output ipsec4_process_packet
1.1 kernel key_allocsp ipsec_getpolicybyaddr
1.0 kernel __mtx_lock_spin_flag
1.0 kernel in_cksumdata in_cksum_skip
1.0 kernel free
1.0 kernel ip_input netisr_dispatch_src
1.0 kernel ether_nh_input netisr_dispatch_src
1.0 kernel bounce_bus_dmamap_lo bus_dmamap_load_mbuf_sg
0.9 kernel _mtx_lock_spin_cooki pmclog_reserve
0.8 kernel m_copydata
0.8 kernel ipsec4_process_packe ip_ipsec_output
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
