Re: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited)
Tested on main-n245400-e75eac2cb81 ___ 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: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited)
On 2021-03-12 12:04, David Wolfskill wrote: > On Thu, Mar 11, 2021 at 07:57:36PM -0800, Alastair Hogge wrote: >> Turns out, EFI boot stopped working. The following boots but fails with >> ... >> umass0: SCSI over Bulk-Only; quirks = 0x4001 >> umass0:6:0: Attached to scbus6 >> Root mount waiting for: usbus5 CAM >> panic: malloc(M_WAITOK) with sleeping prohibited >> cpuid = 0 >> time = 4 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe0081dcf5f0 >> vpanic() at vpanic+0x181/frame 0xfe0081dcf640 >> panic() at panic+0x43/frame 0xfe0081dcf6a0 >> malloc_dbg() at malloc_dbg+0xd4/frame 0xfe0081dcf6c0 >> malloc() at malloc+0x34/frame 0xfe0081dcf720 >> disk_alloc() at disk_alloc+0x1c/frame 0xfe0081dcf740 >> daregister() at daregister+0x3f4/frame 0xfe0081dcf9c0 >> cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfe0081dcfa90 >> daasync() at daasync+0x2c2/frame 0xfe0081dcfb00 >> xpt_async_process_dev() at xpt_async_process_dev+0x152/frame >> 0xfe0081dcfb50 >> xpt_async_process() at xpt_async_process+0x334/frame 0xfe0081dcfc60 >> xpt_done_process() at xpt_done_process+0x3a3/frame 0xfe0081dcfca0 >> xpt_done_td() at xpt_done_td+0xf5/frame 0xfe0081dcfcf0 >> fork_exit() at fork_exit+0x80/frame 0xfe0081dcfd30 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0081dcfd30 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >> > > You may find the change that's in https://reviews.freebsd.org/D29210 > helps -- the trace looks similar to what I saw, and it has worked for > me. > > Note that I only saw the panic while running a kernel with INVARIANTS. Patch works; tested with INVARIANTS only. Thanks all. To good health, Alastair ___ 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: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited)
On 2021-03-12 12:04, David Wolfskill wrote: > On Thu, Mar 11, 2021 at 07:57:36PM -0800, Alastair Hogge wrote: >> Turns out, EFI boot stopped working. The following boots but fails with >> ... >> umass0: SCSI over Bulk-Only; quirks = 0x4001 >> umass0:6:0: Attached to scbus6 >> Root mount waiting for: usbus5 CAM >> panic: malloc(M_WAITOK) with sleeping prohibited >> cpuid = 0 >> time = 4 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe0081dcf5f0 >> vpanic() at vpanic+0x181/frame 0xfe0081dcf640 >> panic() at panic+0x43/frame 0xfe0081dcf6a0 >> malloc_dbg() at malloc_dbg+0xd4/frame 0xfe0081dcf6c0 >> malloc() at malloc+0x34/frame 0xfe0081dcf720 >> disk_alloc() at disk_alloc+0x1c/frame 0xfe0081dcf740 >> daregister() at daregister+0x3f4/frame 0xfe0081dcf9c0 >> cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfe0081dcfa90 >> daasync() at daasync+0x2c2/frame 0xfe0081dcfb00 >> xpt_async_process_dev() at xpt_async_process_dev+0x152/frame >> 0xfe0081dcfb50 >> xpt_async_process() at xpt_async_process+0x334/frame 0xfe0081dcfc60 >> xpt_done_process() at xpt_done_process+0x3a3/frame 0xfe0081dcfca0 >> xpt_done_td() at xpt_done_td+0xf5/frame 0xfe0081dcfcf0 >> fork_exit() at fork_exit+0x80/frame 0xfe0081dcfd30 >> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0081dcfd30 >> --- trap 0, rip = 0, rsp = 0, rbp = 0 --- >> > > You may find the change that's in https://reviews.freebsd.org/D29210 > helps -- the trace looks similar to what I saw, and it has worked for > me. > > Note that I only saw the panic while running a kernel with INVARIANTS. Fantastic! Thanks for those pointers, I will try imp's fix after the current build finishes. To health, Alastair ___ 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: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited)
On Thu, Mar 11, 2021 at 07:57:36PM -0800, Alastair Hogge wrote: > Turns out, EFI boot stopped working. The following boots but fails with > ... > umass0: SCSI over Bulk-Only; quirks = 0x4001 > umass0:6:0: Attached to scbus6 > Root mount waiting for: usbus5 CAM > panic: malloc(M_WAITOK) with sleeping prohibited > cpuid = 0 > time = 4 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe0081dcf5f0 > vpanic() at vpanic+0x181/frame 0xfe0081dcf640 > panic() at panic+0x43/frame 0xfe0081dcf6a0 > malloc_dbg() at malloc_dbg+0xd4/frame 0xfe0081dcf6c0 > malloc() at malloc+0x34/frame 0xfe0081dcf720 > disk_alloc() at disk_alloc+0x1c/frame 0xfe0081dcf740 > daregister() at daregister+0x3f4/frame 0xfe0081dcf9c0 > cam_periph_alloc() at cam_periph_alloc+0x57b/frame 0xfe0081dcfa90 > daasync() at daasync+0x2c2/frame 0xfe0081dcfb00 > xpt_async_process_dev() at xpt_async_process_dev+0x152/frame > 0xfe0081dcfb50 > xpt_async_process() at xpt_async_process+0x334/frame 0xfe0081dcfc60 > xpt_done_process() at xpt_done_process+0x3a3/frame 0xfe0081dcfca0 > xpt_done_td() at xpt_done_td+0xf5/frame 0xfe0081dcfcf0 > fork_exit() at fork_exit+0x80/frame 0xfe0081dcfd30 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe0081dcfd30 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > You may find the change that's in https://reviews.freebsd.org/D29210 helps -- the trace looks similar to what I saw, and it has worked for me. Note that I only saw the panic while running a kernel with INVARIANTS. Peace, david -- David H. Wolfskill da...@catwhisker.org That broadly-popular "American Rescue Plan" (stimulus/COVID relrief)? Ever Republican vote in Congress was against it. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Asus E45M1-M PRO (panic: malloc(M_WAITOK) with sleeping prohibited)
Turns out, EFI boot stopped working. The following boots but fails with umass0:6:0: Attached to scbus6 Root mount waiting for: usbus5 CAM panic: malloc(M_WAITOK) with sleeping prohibited Tested with FreeBSD-14.0-CURRENT-amd64-20210311-15565e0a217-257277-mini-memstick.img OK boot [176/1976] Loading kernel... /boot/kernel/kernel text=0x17f580 text=0xe09440 text=0x6a7ae4 data=0x140 data=0x1c2648+0x43c9b8 syms=[0x8+0x187d28+0x8+0x1a8351] Loading configured modules... can't find '/boot/entropy' can't find '/etc/hostid' GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb ---<>--- Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 14.0-CURRENT #0 main-n245383-15565e0a217: Thu Mar 11 06:32:09 UTC 2021 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) WARNING: WITNESS option enabled, expect reduced performance. VT(vga): resolution 640x480 CPU: AMD E-450 APU with Radeon(tm) HD Graphics (1649.98-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x500f20 Family=0x14 Model=0x2 Stepping=0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff SVM: NP,NRIP,NAsids=8 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 7845748736 (7482 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) arc4random: WARNING: initial seeding bypassed the cryptographic random device because it was not yet seeded and the knob 'bypass_before_seeding' was enabled. Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x/0x1 (20210105/tbfadt-796) ioapic0: MADT APIC ID 0 != hw id 3 ioapic0 irqs 0-23 Launching APs: 1 Timecounter "TSC" frequency 1649980197 Hz quality 800 random: entropy device external interface WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 14.0. kbd1 at kbdmux0 mlx5en: Mellanox Ethernet driver 3.6.0 (December 2020) vtvga0: smbios0: at iomem 0xf0460-0xf047e smbios0: Version: 2.6, BCD Revision: 2.6 aesni0: No AES or SHA support. acpi0: acpi0: Power Button (fixed) cpu0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf000-0xf0ff mem 0xd000-0xdfff,0xfeb0-0xfeb3 irq 18 at device 1.0 on pci0 vgapci0: Boot video device hdac0: mem 0xfeb44000-0xfeb47fff irq 19 at device 1.1 on pci0 pcib1: irq 16 at device 4.0 on pci0 pci1: on pcib1 igb0: mem 0xfe60-0xfe6f,0xfe784000-0xfe787fff irq 16 at device 0.0 on pci1 igb0: Using 1024 TX descriptors and 1024 RX descriptors igb0: Using 2 RX queues 2 TX queues igb0: Using MSI-X interrupts with 3 vectors igb0: Ethernet address: a0:36:9f:07:d9:58 [103/1976] igb0: netmap queues/slots: TX 2/1024, RX 2/1024 igb1: mem 0xfe50-0xfe5f,0xfe78-0xfe783fff irq 17 at device 0.1 on pci1 igb1: Using 1024 TX descriptors and 1024 RX descriptors igb1: Using 2 RX queues 2 TX queues igb1: Using MSI-X interrupts with 3 vectors igb1: Ethernet address: a0:36:9f:07:d9:59 igb1: netmap queues/slots: TX 2/1024, RX 2/1024 ahci0: port 0xf140-0xf147,0xf130-0xf133,0xf120-0xf127,0xf110-0xf113,0xf100-0xf10f mem 0xfeb4f000-0xfeb4f3ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.20 with 6 6Gbps ports, Port Multiplier supported ahci0: quirks=0x22000 ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahc
Re: Getting started with ktls
On Thu, Mar 11, 2021 at 11:49 AM John Baldwin wrote: > On 3/10/21 4:18 PM, Alan Somers wrote: > > I'm trying to make ktls work with "zfs send/recv" to substantially reduce > > the CPU utilization of applications like zrepl. But I have a few > questions: > > > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by a > > successful set of the TCP_TXTLS_ENABLE socket option", but the "Supported > > Libraries" section says "Applications using a supported library should > > generally work with ktls without any changes". These sentences seem to > be > > contradictory. I think it means that the TCP_TXTLS_ENABLE option is > > necessary, but OpenSSL sets it automatically? > > Yes, you can do it by hand if you want but you'd have to do all the key > exchange by hand as well. > > > * When using OpenSSL, the library will automatically call setsockopt(_, > > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > > application to tell if ktls is enabled on a particular socket or OpenSSL > > session? > > BIO_get_ktls_send() and BIO_get_ktls_recv() on the write and read BIO's of > the connection, respectively. > > > * From experiment, I can see that OpenSSL attempts to set > > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why not? > > From reading ktls_start and ossl_statem_server_post_work, it looks like > > maybe a single socket cannot have ktls enabled for both sending and > > receiving at the same time. Is that true? > > Neither FreeBSD nor OpenSSL yet support RX offload on TLS 1.3. If you use > TLS 1.2 you will get KTLS in both directions (or if you use TLS 1.1 with > TOE offload on a Chelsio T6). > > -- > John Baldwin > Switching to TLS 1.2 turned out to be key. Once I did that, ... it just worked. I was expecting to need minor changes throughout the kernel and libzfs. However, that wasn't necessary. Here is my proof-of-concept program. So far only the recv path is implemented. I'll probably implement the send path too, but I'm not currently planning to integrate this into any open-source application. Thanks for all the help! https://github.com/asomers/freebsd-src/tree/ktls-zfs/tools/zfs-ktls -Alan ___ 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: Rationalizing sed -i/-I (in-place editing) argument handling
On Mon, 8 Mar 2021 at 16:41, Ed Maste wrote: > > On Mon, 8 Mar 2021 at 15:55, Ian Lepore wrote: > > > > I also hate the idea of requiring no space between -I and its related > > value. That seems like a huge POLA violation compared to how virtually > > every other command's options and arguments work. > > On the other hand, -i.ext with no space is compatible with FreeBSD > today and is portable to OpenBSD, NetBSD, macOS, and GNU. -i .ext > works only with FreeBSD and macOS. I'd like to go ahead with a man page update shortly. Even if we do not modify sed, it is valuable to document and describe the compatibility issues with our -i/-I, including the odd way we specify no backup file. On the topic of POLA our -i/-I support was based on perl's in-place editing, except perl uses the optional argument style (-i / -i.bak). I'd also argue that our -i "" is a POLA violation compared to how most other commands work, and has caused significant confusion for folks interested in cross-OS compatibility. If anyone has suggestions or improvements to the proposed man page text I'd appreciate a follow-up here or a comment in the review, https://reviews.freebsd.org/D29128. ___ 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: panic: malloc(M_WAITOK) with sleeping prohibited with main-n245383-15565e0a2177
On Thu, Mar 11, 2021 at 12:56:02PM -0500, Mark Johnston wrote: > On Thu, Mar 11, 2021 at 06:32:13PM +0100, Peter Holm wrote: > > I just got this panic: > > > > panic: malloc(M_WAITOK) with sleeping prohibited > > cpuid = 0 > > time = 1615472733 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > 0xfe00e49748b0 > > vpanic() at vpanic+0x181/frame 0xfe00e4974900 > > panic() at panic+0x43/frame 0xfe00e4974960 > > malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e4974980 > > malloc() at malloc+0x34/frame 0xfe00e49749e0 > > g_mirror_event_send() at g_mirror_event_send+0x30/frame 0xfe00e4974a30 > > softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfe00e4974b00 > > softclock() at softclock+0x66/frame 0xfe00e4974b20 > > ithread_loop() at ithread_loop+0x279/frame 0xfe00e4974bb0 > > fork_exit() at fork_exit+0x80/frame 0xfe00e4974bf0 > > fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e4974bf0 > > > > https://people.freebsd.org/~pho/stress/log/log0078.txt > > Hi Peter, > > Could you try the patch here? https://reviews.freebsd.org/D29223 This fixed the problem for me. I ran the problem test for an hour and then the rest of the g_mirror tests. No problems seen. - Peter ___ 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: Getting started with ktls
On 3/10/21 4:18 PM, Alan Somers wrote: I'm trying to make ktls work with "zfs send/recv" to substantially reduce the CPU utilization of applications like zrepl. But I have a few questions: * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by a successful set of the TCP_TXTLS_ENABLE socket option", but the "Supported Libraries" section says "Applications using a supported library should generally work with ktls without any changes". These sentences seem to be contradictory. I think it means that the TCP_TXTLS_ENABLE option is necessary, but OpenSSL sets it automatically? Yes, you can do it by hand if you want but you'd have to do all the key exchange by hand as well. * When using OpenSSL, the library will automatically call setsockopt(_, TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an application to tell if ktls is enabled on a particular socket or OpenSSL session? BIO_get_ktls_send() and BIO_get_ktls_recv() on the write and read BIO's of the connection, respectively. * From experiment, I can see that OpenSSL attempts to set TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why not? From reading ktls_start and ossl_statem_server_post_work, it looks like maybe a single socket cannot have ktls enabled for both sending and receiving at the same time. Is that true? Neither FreeBSD nor OpenSSL yet support RX offload on TLS 1.3. If you use TLS 1.2 you will get KTLS in both directions (or if you use TLS 1.1 with TOE offload on a Chelsio T6). -- 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: panic: malloc(M_WAITOK) with sleeping prohibited with main-n245383-15565e0a2177
On Thu, Mar 11, 2021 at 06:32:13PM +0100, Peter Holm wrote: > I just got this panic: > > panic: malloc(M_WAITOK) with sleeping prohibited > cpuid = 0 > time = 1615472733 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e49748b0 > vpanic() at vpanic+0x181/frame 0xfe00e4974900 > panic() at panic+0x43/frame 0xfe00e4974960 > malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e4974980 > malloc() at malloc+0x34/frame 0xfe00e49749e0 > g_mirror_event_send() at g_mirror_event_send+0x30/frame 0xfe00e4974a30 > softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfe00e4974b00 > softclock() at softclock+0x66/frame 0xfe00e4974b20 > ithread_loop() at ithread_loop+0x279/frame 0xfe00e4974bb0 > fork_exit() at fork_exit+0x80/frame 0xfe00e4974bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e4974bf0 > > https://people.freebsd.org/~pho/stress/log/log0078.txt Hi Peter, Could you try the patch here? https://reviews.freebsd.org/D29223 ___ 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"
panic: malloc(M_WAITOK) with sleeping prohibited with main-n245383-15565e0a2177
I just got this panic: panic: malloc(M_WAITOK) with sleeping prohibited cpuid = 0 time = 1615472733 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e49748b0 vpanic() at vpanic+0x181/frame 0xfe00e4974900 panic() at panic+0x43/frame 0xfe00e4974960 malloc_dbg() at malloc_dbg+0xd4/frame 0xfe00e4974980 malloc() at malloc+0x34/frame 0xfe00e49749e0 g_mirror_event_send() at g_mirror_event_send+0x30/frame 0xfe00e4974a30 softclock_call_cc() at softclock_call_cc+0x15d/frame 0xfe00e4974b00 softclock() at softclock+0x66/frame 0xfe00e4974b20 ithread_loop() at ithread_loop+0x279/frame 0xfe00e4974bb0 fork_exit() at fork_exit+0x80/frame 0xfe00e4974bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe00e4974bf0 https://people.freebsd.org/~pho/stress/log/log0078.txt - Peter ___ 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: Getting started with ktls
I'm going to cheat and top post (the discussion looks pretty convoluted). - The kernel must be built with "options KERN_TLS" - OpenSSL must be built with KTLS enabled - These two sysctls need to be set to 1 kern.ipc.tls.enable kern.ipc.mb_use_ext_pgs then it all happens "behind the curtain" in the OpenSSL libraries. To find out if it is enabled, do the following after the handshake. (SSL_connect() or SSL_accept() or ??) ret = BIO_get_ktls_send(SSL_get_wbio(ssl)); if (ret != 0) ret = BIO_get_ktls_recv(SSL_get_rbio(ssl)); if (ret != 0) /* KTLS enabled for both send and recv. */ The calls return non-zero if it is enabled for that direction. You'll need it to use TLS 1.2 if you want both directions to work at this time. (The code is in usr.sbin/rpc.tlsclntd and usr.sbin/rpc.tlsservd. Much easier to look at than man pages imho.) --> Now you can sosend()/soreceive() on the socket in the kernel. If your data is already in mbufs, then they must be M_EXTPG mbufs. There is a function that copies an mbuf chain into M_EXTPG mbufs, but I can't remember what I called it. rick From: owner-freebsd-curr...@freebsd.org on behalf of Alan Somers Sent: Wednesday, March 10, 2021 10:55 PM To: Benjamin Kaduk Cc: FreeBSD CURRENT Subject: Re: Getting started with ktls CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to ith...@uoguelph.ca On Wed, Mar 10, 2021 at 8:15 PM Benjamin Kaduk wrote: > On Wed, Mar 10, 2021 at 06:17:42PM -0700, Alan Somers wrote: > > On Wed, Mar 10, 2021 at 5:31 PM Benjamin Kaduk wrote: > > > > > On Wed, Mar 10, 2021 at 05:18:24PM -0700, Alan Somers wrote: > > > > I'm trying to make ktls work with "zfs send/recv" to substantially > reduce > > > > the CPU utilization of applications like zrepl. But I have a few > > > questions: > > > > > > > > * ktls(4)'s "Transmit" section says "Once TLS transmit is enabled by > a > > > > successful set of the TCP_TXTLS_ENABLE socket option", but the > "Supported > > > > Libraries" section says "Applications using a supported library > should > > > > generally work with ktls without any changes". These sentences seem > to > > > be > > > > contradictory. I think it means that the TCP_TXTLS_ENABLE option is > > > > necessary, but OpenSSL sets it automatically? > > > > > > Yes, OpenSSL sets it automatically for the builtin socket and > connection > > > BIO classes. Applications using other BIO classes will need to do > things > > > manually (or implement the appropriate _ctrl() parameters for their BIO > > > class). > > > > > > > * When using OpenSSL, the library will automatically call > setsockopt(_, > > > > TCP_TXTLS_ENABLE). But it swallows the error, if any. How is an > > > > application to tell if ktls is enabled on a particular socket or > OpenSSL > > > > session? > > > > > > IIRC the lack of answer for this is part of why upstream OpenSSL > doesn't > > > have specific KTLS tests enabled in the automated test suite. > > > > > > > getsockopt(_. TCP_TXTLS_ENABLE) returns ENOPROTOOPT. Is there any reason > > why it's not implemented? That might be the easiest way to check for the > > ktls status of an individual socket. > > I think that's probably more of a question for jhb than me. I don't know > of a reason why not, but I do know that there is some desire to keep the > functionality that openssl exposes roughly compatible between linux and > FreeBSD KTLS. I don't know whether Linux has something similar. > > > > > > > > > > * From experiment, I can see that OpenSSL attempts to set > > > > TCP_TXTLS_ENABLE. But it doesn't try to set TCP_RXTLS_ENABLE. Why > not? > > > > From reading ktls_start and ossl_statem_server_post_work, it looks > like > > > > maybe a single socket cannot have ktls enabled for both sending and > > > > receiving at the same time. Is that true? > > > > > > No. They just get enabled separately, since change_cipher_state() is > > > called separately for read and write transitions. > > > > > > > Apologies if I'm too ignorant, but what is a transition in SSL-speak? > This > > is my first attempt at any kind of SSL programming. What I know from > > ktrace is that TCP_RXTLS_ENABLE never gets set. > > Sorry! I'm pretty conversant with this stuff (I'm the security area > director that is responsible for the IETF TLS working group) and don't > always target the right level. Basically, for a decent encrypting protocol > you want different encrytion keys for the read and write direction > (whichever peer you are), and the TLS (1.3) handshake has a multi-stage key > hierarchy to try to encrypt as much of it as possible. So, for example, > the client will need to update it's encryption key for reading once it > reads the ServerHello (and
Re: libifconfig_sfp.h does not compile for me
On 3/11/21 3:51 AM, Ronald Klop wrote: Hi, This https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h includes libifconfig_sfp_tables.h which does not exist. My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, but no succes. The last change in these files is a few days ago, am I the only one with this problem? The generated files live only in the obj dir, so after cleaning you'll need to rebuild libifconfig (and not clean) before you can build ifconfig again. make -C lib/libifconfig make -C sbin/ifconfig -Ryan ___ 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: libifconfig_sfp.h does not compile for me
Van: Kurt Jaeger Datum: donderdag, 11 maart 2021 10:04 Aan: Ronald Klop CC: FreeBSD CURRENT Onderwerp: Re: libifconfig_sfp.h does not compile for me Hi! > This https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h includes libifconfig_sfp_tables.h which does not exist. > > My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, but no succes. > The last change in these files is a few days ago, am I the only one with this problem? > > This is on 14-CURRENT/amd64. It looks like libifconfig_sfp_tables.h might be created during the build via the template https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp_tables.tpl.h Maybe this fails to build ? -- p...@opsec.eu+49 171 3101372Now what ? Hi, Thanks for the quick answers. I did some more manual cleaning, but the error keeps coming back. Although I see the generated file in the obj dir. Now nuked the whole /obj dir and doing a clean build. So I will report back after llvm/clang is build again. Probably next week. :-) Regards, Ronald. ___ 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: libifconfig_sfp.h does not compile for me
On 11 Mar 2021, at 9:51, Ronald Klop wrote: Hi, This https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h includes libifconfig_sfp_tables.h which does not exist. My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, but no succes. The last change in these files is a few days ago, am I the only one with this problem? How are you building? libifconfig_sfp_tables.h is a generated file, and the build should have created it. It does for me: /usr/libexec/flua /usr/src/lib/libifconfig/sfp.lua /usr/src/lib/libifconfig/libifconfig_sfp_tables.tpl.h >libifconfig_sfp_tables.h /usr/libexec/flua /usr/src/lib/libifconfig/sfp.lua /usr/src/lib/libifconfig/libifconfig_sfp_tables.tpl.c >libifconfig_sfp_tables.c /usr/libexec/flua /usr/src/lib/libifconfig/sfp.lua /usr/src/lib/libifconfig/libifconfig_sfp_tables_internal.tpl.h >libifconfig_sfp_tables_internal.h Although I do not understand the magical incantations in the makefile that make it do so I can see that they’re there and that they do what’s required. Regards, Kristof ___ 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: libifconfig_sfp.h does not compile for me
Hi! > This https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h > includes libifconfig_sfp_tables.h which does not exist. > > My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, but no > succes. > The last change in these files is a few days ago, am I the only one with this > problem? > > This is on 14-CURRENT/amd64. It looks like libifconfig_sfp_tables.h might be created during the build via the template https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp_tables.tpl.h Maybe this fails to build ? -- p...@opsec.eu+49 171 3101372Now what ? ___ 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"
libifconfig_sfp.h does not compile for me
Hi, This https://cgit.freebsd.org/src/tree/lib/libifconfig/libifconfig_sfp.h includes libifconfig_sfp_tables.h which does not exist. My build fails on this. I cleaned /lib/libifconfig and /sbin/ifconfig, but no succes. The last change in these files is a few days ago, am I the only one with this problem? This is on 14-CURRENT/amd64. Regards, Ronald. ___ 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"
