Re: Speed problems with both system openssl and security/openssl-devel
Hello Lev, Thursday, September 13, 2018, 2:46:46 AM, you wrote: > Linux have openssl 1.1.0f, and I've tried both system /usr/bin/openssl > (1.0.2p) > and /usr/local/bin/openssl from security/openssl-devel port (1.1.0i), results > are > virtually the same. I have "ASM" and "SSE2" options enabled in port. > What happens here? Why does FreeBSD's build of openssl use AES-NI so > inefficient? More datapoints. (1) aes-256-cbc behaves really wired. Time output is completely bogus without "-elapsed" and speed is unbelievably low with "-elapsed". aes-256-gcm doesn't have this anomaly without "-elapsed" (please note "in 0.xxs" here): Doing aes-256-cbc for 3s on 16 size blocks: 503555 aes-256-cbc's in 0.60s Doing aes-256-cbc for 3s on 64 size blocks: 520386 aes-256-cbc's in 0.54s Doing aes-256-cbc for 3s on 256 size blocks: 435106 aes-256-cbc's in 0.44s Doing aes-256-cbc for 3s on 1024 size blocks: 242832 aes-256-cbc's in 0.38s Doing aes-256-cbc for 3s on 8192 size blocks: 49087 aes-256-cbc's in 0.09s ... aes-256-cbc 13393.26k61782.64k 254599.17k 663093.25k 4289287.51k Doing aes-256-gcm for 3s on 16 size blocks: 12051311 aes-256-gcm's in 3.03s Doing aes-256-gcm for 3s on 64 size blocks: 6428598 aes-256-gcm's in 3.04s Doing aes-256-gcm for 3s on 256 size blocks: 2122316 aes-256-gcm's in 3.00s Doing aes-256-gcm for 3s on 1024 size blocks: 610443 aes-256-gcm's in 3.13s Doing aes-256-gcm for 3s on 8192 size blocks: 75836 aes-256-gcm's in 3.03s ... aes-256-gcm 63611.04k 135380.66k 181104.30k 199531.13k 204947.96k with "-elapsed": Doing aes-256-cbc for 3s on 16 size blocks: 493829 aes-256-cbc's in 3.01s Doing aes-256-cbc for 3s on 64 size blocks: 530550 aes-256-cbc's in 3.06s Doing aes-256-cbc for 3s on 256 size blocks: 426699 aes-256-cbc's in 3.01s Doing aes-256-cbc for 3s on 1024 size blocks: 243305 aes-256-cbc's in 3.03s Doing aes-256-cbc for 3s on 8192 size blocks: 48069 aes-256-cbc's in 3.01s ... aes-256-cbc 2626.91k11087.41k36317.07k82191.94k 130919.48k Doing aes-256-gcm for 3s on 16 size blocks: 12041385 aes-256-gcm's in 3.08s Doing aes-256-gcm for 3s on 64 size blocks: 6445757 aes-256-gcm's in 3.05s Doing aes-256-gcm for 3s on 256 size blocks: 2129499 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 1024 size blocks: 587396 aes-256-gcm's in 3.01s Doing aes-256-gcm for 3s on 8192 size blocks: 75806 aes-256-gcm's in 3.03s ... aes-256-gcm 62590.75k 135047.68k 181245.26k 199977.06k 204866.89k (2) I've added debug output to 'crypto/evp/e_aes.c' and it shows, that AES-NIU should be used. (3) openssl111 from ports doesn't show these problems. -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD EFI projects
On 17 September 2018 at 14:17, Warner Losh wrote: > Items on my list are: > > (1) Retiring boot1.efi entirely before 13.0. It was originally designed to > be a small, never changing blob we'd toss into an ESP and have all the > smarts in loader.efi. I'd go further than this: it was originally designed as a stopgap to have FreeBSD work in an EFI world when we didn't support the standard UEFI interfaces and did not have a straightforward way for loader.efi to find its script/configuration files in a different partition or filesystem. As far as I recall it was never intended to be a permanent part of the UEFI boot process. We'll probably reacquire a small first-stage UEFI boot component: the UEFI Secure Boot shim loader. But it can load loader.efi from the ESP and won't be used outside of Secure Boot configurations. > Moving to a > 'standard' setup for EFI would be a good first step, as well as having a > script to do this both for when the ESP is mounted in a non-standard place, > as well as for when it's not mounted. I'm not sure how far we have to go in catering to non-standard configurations. I completely agree we should have a standard EFI configuration and should support seamless upgrades in that configuration. For other cases I'd personally just ensure we've fully documented the components and processes. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD EFI projects
On Mon, Sep 17, 2018 at 12:17:25PM -0600, Warner Losh wrote: > On Sun, Sep 16, 2018 at 11:29 PM Rebecca Cran wrote: > I've had some interest on #bsdmips about booting a 64-bit FreeBSD on old > > Apple systems that use 32-bit EFI: it sounds like it should be possible, > > and is something I'd like to try and get working. > > > > That should be possible, but there's a number of issue dealing with the > 32-bit EFI not having a direct map that we can use to generate the mapping > tables we need for the loader early in our boot. It's why we can't call the > EFI runtime on armv7, for example. Having EFI RT working when 64bit kernel is booted from 32bit EFI environment is very non-trivial. DMAP is not an issue at all, loaders do not use or need it (in fact loaders run with the 1:1 mapping or disabled paging). RT requires calling into 32 bit mode from 64 bit. This is hard to do since kernel interrupt and fault handlers assume that kernel mode means flat 64bit. Interrupts would switch to 64 bit, but existing kernel code cannot handle such switch. Just do not provide RT for 32bit EFI. That said, making only the loader->kernel transition from EFI 32bit to 64bit kernel should be not too hard, and even significantly simpler than to make 32bit EFI load 32bit kernel. amd64 kernels already aware that there might be no BIOS and they do not try to make vm86 calls into real code, and only read memory map from the loader metadata etc. Besides old Macs, this should also benefit newer Intel embedded-like boards. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
On 9/17/18 11:32 AM, Michael Butler wrote: > On 9/10/18 1:20 PM, John Baldwin wrote: >> On 9/8/18 1:44 PM, Michael Butler wrote: >>> On 9/8/18 3:43 PM, Konstantin Belousov wrote: On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote: > On 8/31/18 1:28 AM, Konstantin Belousov wrote: >> On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote: > > [ .. snip .. ] > >>> I see another problem after using Ian's workaround of moving the #ifdef >>> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) >>> machine with only 512MB of RAM: >>> >>> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed >>> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed >>> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed >>> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >>> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >>> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed >> >> What is the kernel revision for "now". What was the previous revision >> where the kstack allocation failures did not happen. >> >> Also, what is the workload ? > > Sorry for the delay. Any version at or after SVN r338360 would either a) > not boot at all or b) crash shortly after boot with a swarm of messages > as above. It was stable before that. > > Unfortunately, this machine is remote and, being as old as it is, has no > remote console facility. 'nextboot' has been my savior ;-) > > It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces, > local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an > OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a > router/firewall with few actual applications running. > > As another data point, I manually reversed both SVN r338360 and r338415 > (a related change) and it is now stable running at SVN r338520, It is very unprobable. I do not see how could r338360 affect KVA allocation. Double-check that you booted right kernels. >>> >>> FreeBSD sarah.protected-networks.net 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #14 >>> r338520M: Thu Sep 6 21:35:31 EDT 2018 >>> >>> 'svn diff' reports the only changes being the two reversals I noted above, >> >> Can you get the output of 'x num_io_irqs' at the DDB prompt after the >> panic? >> > > SVN r338725 fixed this - thanks! :-) Hmm, I'm not sure how that fixed this, but glad it is ok now. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
On 9/10/18 1:20 PM, John Baldwin wrote: > On 9/8/18 1:44 PM, Michael Butler wrote: >> On 9/8/18 3:43 PM, Konstantin Belousov wrote: >>> On Sat, Sep 08, 2018 at 02:07:41PM -0400, Michael Butler wrote: On 8/31/18 1:28 AM, Konstantin Belousov wrote: > On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote: [ .. snip .. ] >> I see another problem after using Ian's workaround of moving the #ifdef >> SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) >> machine with only 512MB of RAM: >> >> Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed >> Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed > > What is the kernel revision for "now". What was the previous revision > where the kstack allocation failures did not happen. > > Also, what is the workload ? Sorry for the delay. Any version at or after SVN r338360 would either a) not boot at all or b) crash shortly after boot with a swarm of messages as above. It was stable before that. Unfortunately, this machine is remote and, being as old as it is, has no remote console facility. 'nextboot' has been my savior ;-) It is a 700MHz Pentium-III with 512MB of RAM and has 3 used interfaces, local ethernet (FXP), GIF for an IPv6 tunnel to HE and TAP for an OpenVPN endpoint. It has IPFW compiled into the kernel and acts as a router/firewall with few actual applications running. As another data point, I manually reversed both SVN r338360 and r338415 (a related change) and it is now stable running at SVN r338520, >>> >>> It is very unprobable. I do not see how could r338360 affect KVA >>> allocation. >>> Double-check that you booted right kernels. >>> >> >> FreeBSD sarah.protected-networks.net 12.0-ALPHA5 FreeBSD 12.0-ALPHA5 #14 >> r338520M: Thu Sep 6 21:35:31 EDT 2018 >> >> 'svn diff' reports the only changes being the two reversals I noted above, > > Can you get the output of 'x num_io_irqs' at the DDB prompt after the > panic? > SVN r338725 fixed this - thanks! :-) imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD EFI projects
On Sun, Sep 16, 2018 at 11:29 PM Rebecca Cran wrote: > On 9/16/18 9:32 PM, Warner Losh wrote: > > > > > What did you have in mind working on? I have a few things that are in > > various stages of completeness around this issue that I've not had > > time to polish off for the tree. Some I'd like to, but some may > > benefit from a fresh perspective. Also, there's a fair number of > > hidden bugs in the stuff committed around finding the whole path > > sometimes and the like. > > > One thing I've started working on is switching the ESP to use FAT32 > everywhere except the ISO images (due to the limitation in the El Torito > format not supporting sufficiently large regions). The specifications > from EFI 1.10 onward have been clear that only FAT32 is supported for > the ESP (but that FAT12 and FAT16 must be supported for removable > devices), and I've read that some systems do enforce that. Unfortunately > that does mean the ESP must be a minimum of 33MB, but I think it's > worthwhile for increased compatibility. > I think this is a good change. We've seen issues with the tiny systems and FAT12 format, so we've switched to FAT16. But even with that, we're seeing some issues, so using FAT32 is great. > Related to that, I've also been working on removing the FAT filesystem > templates that are currently checked into svn, instead generating them > during the release stage. > I'd like to simply remove them entirely. They serve no useful purpose if we have an installer / script that can newfs + copy files. they were originally done so that we didn't have to change geom too much and could just DD something to a partition, which matched well the GPT boot code case. I've had some interest on #bsdmips about booting a 64-bit FreeBSD on old > Apple systems that use 32-bit EFI: it sounds like it should be possible, > and is something I'd like to try and get working. > That should be possible, but there's a number of issue dealing with the 32-bit EFI not having a direct map that we can use to generate the mapping tables we need for the loader early in our boot. It's why we can't call the EFI runtime on armv7, for example. > I'd also really like to help move the changes to mount an existing ESP > during installation instead of clobbering it towards being committed, if > possible. > Another very worthwhile project. > Another thing I'd like to work on is trying to catch corner cases like > in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210244 where > calling GetMemoryMap causes the memory map to become fragmented. I'd > also like to try and improve diagnostics, for example at the moment if > the system doesn't have enough memory to run the loader it silently > exits instead of displaying an error message. > That would be awesome. When things work today, they work. When they don't, it an be quite opaque to figure out, absent help from kib :). > And I would also be interested in taking a look at any projects you've > not completed yet, to see if I can help in any way. > Items on my list are: (1) Retiring boot1.efi entirely before 13.0. It was originally designed to be a small, never changing blob we'd toss into an ESP and have all the smarts in loader.efi. However, to support GELI encryption, ZFS, and other things, it's had to grow an increasingly frustrating amount of functionality. Better to just use loader.efi. This does, however, require that we solve the problem of updating loader.efi on installworld / freebsd-update times, even on systems with non-standard setups. Moving to a 'standard' setup for EFI would be a good first step, as well as having a script to do this both for when the ESP is mounted in a non-standard place, as well as for when it's not mounted. (2) Create a /dev/efi/boot for the drive/partition that we booted off of. This will allow us to have a standard fstab which is more resilient to oddities. NanoBSD could use this for it's ping-pong setup. I have some very basic code here, but it's more the stubs to add this to geom, and not so much on finding this information. Might be nice to also have a /dev/efi/esp to identify the ESP we booted off of as well to cope with systems that may have multiple potential ESP locations (at work we have this sort of setup for redundancy). (3) Add network interfaces to things that we know how to generate EFI DEVICE PATH entries for. I have some preliminary code that tries to match up the ifnet entries with a MAC DEVICE_PATH that I'd hoped to use to add netbooting support to efibootmgr. (4) Final integration of efibootmgr into the installer so we can generally install things robustly. Sadly, this has issues with some BIOSes not honoring BootOrder. I have no code, but have been working with nathanw@ on this. (5) For those systems that do honor BootOrder, having nextboot implemented using EFI variables would be sweet. I have vague ideas on this only. Warner ___ freebsd-current@freebsd.org mailing list
vtnet + gif (IPv4 in IPv4) + iperf3 leads to crash on ALPHA6
I'm preparing some benchmarking setup, which includes gif tunnel from FreeBSD to FreeBSD, where one end is 12.0-ALPHA6/r338707 installed as guest in VirtualBox with virtual NIC (vtnet). This tunnel works for simple pings, but when I run iperf3 on this "link" ALPHA4 system crashes. It is 100% reproducible for me. panic: Assertion !in_epoch(net_epoch_preempt) && !mtx_owned(&(&(tcbinfo))->ipi_lock) failed at /data/src/sys/netinet/tcp_input.c:803 cpuid = 0 time = 1537187018 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe44a310 vpanic() at vpanic+0x1a3/frame 0xfe44a370 panic() at panic+0x43/frame 0xfe44a3d0 tcp_input() at tcp_input+0x16a9/frame 0xfe44a520 ip_input() at ip_input+0x126/frame 0xfe44a5a0 netisr_dispatch_src() at netisr_dispatch_src+0x83/frame 0xfe44a600 gif_input() at gif_input+0x2db/frame 0xfe44a640 in_gif_input() at in_gif_input+0x73/frame 0xfe44a680 encap_input() at encap_input+0x1cf/frame 0xfe44a6f0 encap4_input() at encap4_input+0x28/frame 0xfe44a720 ip_input() at ip_input+0x126/frame 0xfe44a7a0 netisr_dispatch_src() at netisr_dispatch_src+0x83/frame 0xfe44a800 ether_demux() at ether_demux+0x15e/frame 0xfe44a830 ether_nh_input() at ether_nh_input+0x373/frame 0xfe44a880 netisr_dispatch_src() at netisr_dispatch_src+0x83/frame 0xfe44a8e0 ether_input() at ether_input+0x42/frame 0xfe44a900 vtnet_rxq_eof() at vtnet_rxq_eof+0x736/frame 0xfe44a9a0 vtnet_rx_vq_intr() at vtnet_rx_vq_intr+0x58/frame 0xfe44a9d0 vtpci_legacy_intr() at vtpci_legacy_intr+0xb0/frame 0xfe44aa10 ithread_loop() at ithread_loop+0x140/frame 0xfe44aa70 fork_exit() at fork_exit+0x84/frame 0xfe44aab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe44aab0 -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Speed problems with both system openssl and security/openssl-devel
On 17.09.2018 10:40, Daniel Nebdal wrote: > Could it be relevant that the Debian binary was probably compiled with > gcc, and the FreeBSD binary with clang? Maybe. Now I'm trying to trace codepath of "openssl speed -evp aes-256-cbc" on FreeBSD to understand where and why it refuses to use AES. No much luck, though, openssl sources are very convoluted :-( > This seems like the sort of code that plausibly could bring out some > compiler corner cases. (It's weird that 1.1.1 is fine, though.) -- // Lev Serebryakov ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
12.0-ALPHA6-amd64-20180914-r338675 LOR?
Hi, I am trying out 12.0-ALPHA6-amd64-20180914-r338675 vmdk with a VM with two CPUs. When doing "shutdown -h now" I get a lock order reversal, is this expected? According to https://www.freebsd.org/doc/faq/troubleshoot.html#idp59076936 it is possible to get false positives from witness. Attaching output: root@freebsd:~ # shutdown -h now shutdown -h now Shutdown NOW! Sep 17 11:05:04 Stopping cron. Waiting for PIDS: 676. Stopping devd. Waiting for PIDS: 420. Writing entropy file:. Writing early boot entropy file:. Terminated . Sep 17 11:05:05 freebsd syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 2 0 done Waiting (max 60 seconds) for system thread `bufdaemon' to stop... done Waiting (max 60 seconds) for system thread `bufspacedaemon-0' to stop... done All buffers synced. lock order reversal: 1st 0xf80003702ba8 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1343 2nd 0xf80003703248 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2590 stack backtrace: #0 0x80bf4203 at witness_debugger+0x73 #1 0x80bf3f53 at witness_checkorder+0xab3 #2 0x80b60bea at lockmgr_lock_fast_path+0x17a #3 0x811df192 at VOP_LOCK1_APV+0xa2 #4 0x80c6eae0 at _vn_lock+0x60 #5 0x80c5d5ff at vget+0x5f #6 0x80a4646d at devfs_allocv+0xdd #7 0x80a45f73 at devfs_root+0x43 #8 0x80c5e09a at vflush+0x6a #9 0x80a45e73 at devfs_unmount+0x43 #10 0x80c55e45 at dounmount+0x515 #11 0x80c5f4d4 at vfs_unmountall+0xc4 #12 0x80c3bc05 at bufshutdown+0x2c5 #13 0x80b8bec8 at kern_reboot+0x218 #14 0x80b8bc59 at sys_reboot+0x3a9 #15 0x8105feec at amd64_syscall+0x28c #16 0x8103c65d at fast_syscall_common+0x101 Uptime: 1m0s The operating system has halted. Please press any key to reboot. BR, Anton Haglund signature.asc Description: PGP signature
Re: Speed problems with both system openssl and security/openssl-devel
On Fri, 14 Sep 2018 at 02:12, Lev Serebryakov wrote: > > Hello John, > > Friday, September 14, 2018, 1:44:13 AM, you wrote: > > >> % grep aesni ~/nanobsd/gatevay.v3/J3160 > >> device aesni > > > From my understanding of the OpenSSL code, it doesn't use the kernel driver > > at all (the kernel driver is only needed for in-kernel crypto such as IPSec > > or GELI). > It is my understanding too. > > > AESNI are just instructions that can be used in userland, and > > OpenSSL's AESNI acceleration is purely different routines in userland. > > I would verify if AESNI shows up in the CPU features in dmesg first (if it > > doesn't I'd check for a BIOS option disabling it). > It is enabled. It is used for sure by openssl 1.1.0 on Linux and bu openssl > 1.1.1 > on FreeBSD, but not by openssl 1.0.2 and 1.1.0 on FreeBSD. Problem is, > openssl 1.1.1 is not used by anything on FreeBSD (yet) and almost > everything uses system (1.0.2) and only some other ports could use 1.1.0 > from ports. > > -- > Best regards, > Levmailto:l...@freebsd.org > Could it be relevant that the Debian binary was probably compiled with gcc, and the FreeBSD binary with clang? This seems like the sort of code that plausibly could bring out some compiler corner cases. (It's weird that 1.1.1 is fine, though.) -- Daniel Nebdal ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: udp6: Page fault panics
On 16.09.2018 03:04, Larry Rosenman wrote:
> vpanic() at vpanic+0x1a3/frame 0xfe00ca17c150
> panic() at panic+0x43/frame 0xfe00ca17c1b0
> trap_fatal() at trap_fatal+0x35f/frame 0xfe00ca17c200
> trap_pfault() at trap_pfault+0x49/frame 0xfe00ca17c260
> trap() at trap+0x2ba/frame 0xfe00ca17c370
> calltrap() at calltrap+0x8/frame 0xfe00ca17c370
> --- trap 0xc, rip = 0x80631428, rsp = 0xfe00ca17c440, rbp =
> 0xfe00ca17c480 ---
> selectroute() at selectroute+0x198/frame 0xfe00ca17c480
> in6_selectroute_fib() at in6_selectroute_fib+0xf/frame 0xfe00ca17c4a0
> ip6_output() at ip6_output+0xfd7/frame 0xfe00ca17c710
(kgdb) l *selectroute+0x198
0x80de14c8 is in selectroute
(/home/devel/freebsd/base/head/sys/netinet6/in6_src.c:736).
731 * Use a cached route if it exists and is valid, else try to
allocate
732 * a new one. Note that we should check the address family of
the
733 * cached destination, in case of sharing the cache with IPv4.
734 */
735 if (ro) {
736 if (ro->ro_rt &&
737 (!(ro->ro_rt->rt_flags & RTF_UP) ||
738 ((struct sockaddr *)(>ro_dst))->sa_family !=
AF_INET6 ||
739
!IN6_ARE_ADDR_EQUAL((>ro_dst)->sin6_addr,
740 dst))) {
> calltrap() at calltrap+0x8/frame 0xfe00c9d863e0
> --- trap 0xc, rip = 0x80636b2b, rsp = 0xfe00c9d864b0, rbp =
> 0xfe00c9d86710 ---
> ip6_output() at ip6_output+0xeeb/frame 0xfe00c9d86710
> udp6_send() at udp6_send+0x720/frame 0xfe00c9d868d0
(kgdb) l *ip6_output+0xeeb
0x80de75bb is in ip6_output
(/home/devel/freebsd/base/head/sys/netinet6/ip6_output.c:531).
526 */
527 if (inp) {
528 ro->ro_dst.sin6_family = AF_INET6;
529 RT_VALIDATE((struct route *)ro, >inp_rt_cookie,
fibnum);
530 }
531 if (ro->ro_rt && fwd_tag == NULL && (ro->ro_rt->rt_flags &
RTF_UP) &&
532 ro->ro_dst.sin6_family == AF_INET6 &&
533 IN6_ARE_ADDR_EQUAL(>ro_dst.sin6_addr, >ip6_dst)) {
534 rt = ro->ro_rt;
535 ifp = ro->ro_rt->rt_ifp;
It looks like Ryan's assumption is correct and panics happen due to
several threads use the same PCB and then route cache invalidation happens.
https://lists.freebsd.org/pipermail/freebsd-net/2018-September/051563.html
But IPv6 path also needs similar patch.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
updating my pordriere oven to latest CURRENT
Hello, I'm short before updating my poudriere oven, a Dell PowerEdge r210, from r318593 to r338641. I have there a ZFS in use for poudriere, created with: # zpool create poudriere /dev/da1 and set in /usr/local/etc/poudriere.conf: ZPOOL=poudriere ZROOTFS=/poudriere # zpool list NAMESIZE ALLOC FREE EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT poudriere 278G 3.90G 274G -13% 1% 1.00x ONLINE - # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) poudriere on /poudriere (zfs, local, nfsv4acls) poudriere/poudriere on /poudriere/poudriere (zfs, local, nfsv4acls) poudriere/poudriere/jails on /poudriere/poudriere/jails (zfs, local, nfsv4acls) ... Before running 'make installkernel' ... and later updating the poudriere tool itself from ports too, I wanted to ask if I have to take care about anything before. I've read src/UPDATING between the above mentioned versions and can't see anything, i.e. the zpool should be fine after the update too. Any comments on this? Thanks matthias -- Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
