terminal tab stop incorrect until reset

[Ted Unangst]

This came up long ago, but I've lost the mail, and the problem remains.

When printing a line of text containing vt100 escapes and tabs, the tab stops
are not set correctly. After running reset, they are.

Repro:

Open a new xterm and run printf "\e[32m\tgreen\e[0m\n".

Observe four space indent.

Run reset and run printf again. Observe eight spaces.

One of the magic OXTABS bits needs to be adjusted? I thought that was the
proposed resolution?

immediate acpitz shutdown

[Ted Unangst]

Turned on my laptop (samsung 9 ativ) and immediately shutdown because acpitz
was 144C. That seems rather unlikely.

This repeated through a few reboots, and also after going back to a previous
kernel, so I'm not sure if anything changed. It just woke up unhappy today.

Probably not actionable, but reporting for the record.


OpenBSD 6.6-current (GENERIC.MP) #583: Wed Jan  1 12:21:07 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8480653312 (8087MB)
avail mem = 8211169280 (7830MB)
User Kernel Config
UKC> disable acpitz
418 acpitz* disabled
UKC> quit
Continuing...
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed250 (77 entries)
bios0: vendor American Megatrends Inc. version "P03AEU.079.150709.MK" date 
07/09/2015
bios0: SAMSUNG ELECTRONICS CO., LTD. 930X2K/931X2K
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI LPIT MSDM SSDT SSDT 
SSDT SSDT SSDT DMAR CSRT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) 
RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) 
RP05(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) M-5Y31 CPU @ 0.90GHz, 1995.73 MHz, 06-3d-04
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) M-5Y31 CPU @ 0.90GHz, 1995.39 MHz, 06-3d-04
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) M-5Y31 CPU @ 0.90GHz, 1995.39 MHz, 06-3d-04
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) M-5Y31 CPU @ 0.90GHz, 1995.38 MHz, 06-3d-04
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus -1 (RP01)
acpiprt5 at acpi0: bus -1 (RP02)
acpiprt6 at acpi0: bus 1 (RP03)
acpiprt7 at acpi0: bus -1 (RP04)
acpiprt8 at acpi0: bus -1 (RP05)
acpiprt9 at acpi0: bus -1 (RP06)
acpiprt10 at acpi0: bus -1 (RP07)
acpiprt11 at acpi0: bus -1 (RP08)
acpiec0 at acpi0
acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpipwrres0 at 

ryzen disabled L3 cache

[Ted Unangst]

An oddity I noticed in dmesg:

cpu0: AMD Ryzen 7 3700X 8-Core Processor, 3600.44 MHz, 17-71-00
cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line
8-way L2 cache, 32MB 64b/line disabled L3 cache

Why is my L3 cache disabled? I saw some other ryzen dmesg reports, but for
different CPU models, and none of them said disabled. Is this an openbsd
reporting problem or a system problem?


OpenBSD 6.6-current (GENERIC.MP) #484: Fri Nov 22 08:53:13 MST 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 68651323392 (65471MB)
avail mem = 66558337024 (63474MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe6cf0 (62 entries)
bios0: vendor American Megatrends Inc. version "B.30" date 10/29/2019
bios0: Micro-Star International Co., Ltd. MS-7A38
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT SSDT MCFG HPET UEFI IVRS PCCT 
SSDT CRAT CDIT BGRT SSDT SSDT WSMT
acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) 
GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) 
GPPF(S4) GP10(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 3700X 8-Core Processor, 3600.44 MHz, 17-71-00
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache, 32MB 64b/line disabled L3 cache
cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: AMD Ryzen 7 3700X 8-Core Processor, 3599.99 MHz, 17-71-00
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache, 32MB 64b/line disabled L3 cache
cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: AMD Ryzen 7 3700X 8-Core Processor, 3599.99 MHz, 17-71-00
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache, 32MB 64b/line disabled L3 cache
cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: AMD Ryzen 7 3700X 8-Core Processor, 3599.99 MHz, 17-71-00
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 
8-way L2 cache, 32MB 64b/line disabled L3 cache
cpu3: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu3: smt 0, core 3, package 0
cpu4 

Re: ios 13 dhcpd vs dhclient stale lease

[Ted Unangst]

Ted Unangst wrote:
> I'm not sure where the bug is exactly (seems probable it could be an apple
> problem), but for the record...

I think this was fixed with an apple update? Nothing in the release notes of
course, but it doesn't seem to happen anymore.

Re: ssh asks for key password incorrectly?

[Ted Unangst]

Damien Miller wrote:
> On Sun, 20 Oct 2019, Ted Unangst wrote:
> 
> > Ah, so when this happens, it's on a machine that doesn't have 
> > id_ed25519.pub.
> > Here's a before and after ssh -vvv for reference.
> 
> ah, so you have just the private key id_ed25519 and no corresponding
> pubkey on this machine?

not intentionally, just happenstance. anyway, since that seems to be the root
cuase, and it's kinda odd, feel free to ignore if this is how it should work.

Re: ssh asks for key password incorrectly?

[Ted Unangst]

Damien Miller wrote:
> On Sun, 20 Oct 2019, Ted Unangst wrote:
> 
> > I have two OpenBSD machines, let's call them laptop and desktop. desktop is 
> > a
> > bit older, and has a ecdsa-sha2-nistp256 key in .ssh/authorized_keys. laptop
> > is configured with a ssh-ed25519 .ssh/id_ed25519 key file. The keyfile has a
> > password and I use ssh-agent and ssh-add to unlock it.
> > 
> > What happens: I ssh from laptop to desktop and ssh asks for the id_ed25519
> > password. This doesn't accomplish much, since it isn't authorized on desktop
> > anyway.
> > 
> > Expected: If the key doesn't work, I should be asked for the remote system
> > password, not the key password. The key has already been unlocked via 
> > ssh-add.
> > 
> > Theory: ssh tries the key, doesn't work, then gets confused when it goes 
> > back
> > into the .ssh for more options and asks to unlock a key it's already seen.
> > 
> > I think this is a regression, I've had similar setup for ages and never
> > noticed this before.
> 
> Could you send the output of "ssh -vvv desktop" from the laptop side?
> Also, what are the permissions for ~/.ssh/id_ed25519*?

Ah, so when this happens, it's on a machine that doesn't have id_ed25519.pub.
Here's a before and after ssh -vvv for reference.

Note that it works fine (without the pub key) connecting to a host that does
have authorized_keys including ed25519.

ativ:~> ssh -vvv 10.3.3.32
OpenSSH_8.1, LibreSSL 3.0.2
debug1: Reading configuration data /home/tedu/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: resolve_canonicalize: hostname 10.3.3.32 is address
debug1: auto-mux: Trying existing master
debug1: Control socket "/home/tedu/.ssh/ctrl-tedu@10.3.3.32:22" does not exist
debug2: ssh_connect_direct
debug1: Connecting to 10.3.3.32 [10.3.3.32] port 22.
debug1: Connection established.
debug1: identity file /home/tedu/.ssh/id_rsa type -1
debug1: identity file /home/tedu/.ssh/id_rsa-cert type -1
debug1: identity file /home/tedu/.ssh/id_dsa type -1
debug1: identity file /home/tedu/.ssh/id_dsa-cert type -1
debug1: identity file /home/tedu/.ssh/id_ecdsa type -1
debug1: identity file /home/tedu/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tedu/.ssh/id_ed25519 type -1
debug1: identity file /home/tedu/.ssh/id_ed25519-cert type -1
debug1: identity file /home/tedu/.ssh/id_xmss type -1
debug1: identity file /home/tedu/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9
debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x0400
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.3.3.32:22 as 'tedu'
debug3: hostkeys_foreach: reading file "/home/tedu/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file 
/home/tedu/.ssh/known_hosts:5
debug3: load_hostkeys: loaded 1 keys from 10.3.3.32
debug3: order_hostkeyalgs: prefer hostkeyalgs: 
ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: 
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: 
ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-...@openssh.com,rsa-sha2-512-cert-...@openssh.com,rsa-sha2-256-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: 
chacha20-poly1...@openssh.com,aes128-ctr,aes128-...@openssh.com
debug2: ciphers stoc: 
chacha20-poly1...@openssh.com,aes128-ctr,aes128-...@openssh.com
debug2: MACs ctos: 
umac-64-...@openssh.com,umac...@openssh.com,hmac-sha2-256,hmac-sha1
debug2: MACs stoc: 
umac-64-...@openssh.com,umac...@openssh.com,hmac-sha2-256,hmac-sha1
debug2: compression ctos: none,z...@openssh.com,zlib
debug2: compression stoc: none,z...@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: 
curve25519-sha256,curve25519-sha...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha

ssh asks for key password incorrectly?

[Ted Unangst]

I have two OpenBSD machines, let's call them laptop and desktop. desktop is a
bit older, and has a ecdsa-sha2-nistp256 key in .ssh/authorized_keys. laptop
is configured with a ssh-ed25519 .ssh/id_ed25519 key file. The keyfile has a
password and I use ssh-agent and ssh-add to unlock it.

What happens: I ssh from laptop to desktop and ssh asks for the id_ed25519
password. This doesn't accomplish much, since it isn't authorized on desktop
anyway.

Expected: If the key doesn't work, I should be asked for the remote system
password, not the key password. The key has already been unlocked via ssh-add.

Theory: ssh tries the key, doesn't work, then gets confused when it goes back
into the .ssh for more options and asks to unlock a key it's already seen.

I think this is a regression, I've had similar setup for ages and never
noticed this before.

ios 13 dhcpd vs dhclient stale lease

[Ted Unangst]

I'm not sure where the bug is exactly (seems probable it could be an apple
problem), but for the record...

When my laptop roams from my home wifi to my phone hotspot, it retains the
same IP it had on the home network, which doesn't work with the phone network.
Running dhclient manually results in it supposedly getting the same IP:
iwm0: bound to 10.3.3.63 from 172.20.10.1

The only way to get a working IP is to delete the dhclient.leases file, then
run it again. At last:
iwm0: bound to 172.20.10.6 from 172.20.10.1

I'm not sure what can be done. Does ios echo back our suggestion incorrectly?
Does it return some result that dhclient misinterprets? No idea. We could
detect this condition perhaps? Anyway, there's a workaround for affected
people.

Re: Bypass doas password check with chroot

[Ted Unangst]

Ted Unangst wrote:
> I think this is not the right note, but after some review I just realized we
> don't ever say that a password is required. It's merely hinted at in various
> options. I'll make a note of that.

Just a simple sentence, but I think it makes explicit the behavior.


Index: doas.1
===
RCS file: /home/cvs/src/usr.bin/doas/doas.1,v
retrieving revision 1.22
diff -u -p -r1.22 doas.1
--- doas.1  21 Jun 2019 17:02:27 -  1.22
+++ doas.1  4 Jul 2019 15:29:00 -
@@ -40,6 +40,9 @@ or
 .Fl s
 is specified.
 .Pp
+The user will be required to authenticate by entering their password,
+unless configured otherwise.
+.Pp
 By default, a new environment is created.
 The variables
 .Ev HOME ,

Re: Bypass doas password check with chroot

[Ted Unangst]

cho...@jtan.com wrote:
> Ingo Schwarze writes:
> > I see nothing wrong with it.  It is easier to describe in the manual
> 
> Indeed I was not suggesting that there was something wrong; being asked for a 
> password when doing something which root could implicitly do simply confused 
> me for a moment which prompted figuring out what the situation was.
> 
> > The bikeshed has already been painted, and no matter whether you are
> > justified in calling the colour that tedu@ chose "pink", i wouldn't
> > see an obvious benefit in re-painting it now.
> 
> I have no desire to change this behaviour or engage in bike-shedding. Please 
> no. Perhaps instead 5 free lines?

I think this is not the right note, but after some review I just realized we
don't ever say that a password is required. It's merely hinted at in various
options. I'll make a note of that.

> 
> --- doas.1.~1.19.~  Sun Sep  4 18:20:37 2016
> +++ doas.1  Thu Jul  4 01:26:21 2019
> @@ -85,6 +85,12 @@
>  Execute the command as
>  .Ar user .
>  The default is root.
> +.Sh NOTE
> +Although the kernel imposes no restrictions on the root user's ability
> +to pose as any other user,
> +.Nm
> +will always require a password as per its configuration in order to
> +keep unnecessary complications out of a critical security utility.
>  .El
>  .Sh EXIT STATUS
>  .Ex -std doas
> 
> Not necessary of course but would have been nice for my peace of mind the 
> other day when it happened (ie. to know that the situation has been duly 
> considered). btw. I've never done anything with mdoc before so I expect 
> there's a better macro to use to head this than .Sh but that's really not the 
> point.
> 
> > Please do not cross-post between different OpenBSD lists.
> 
> Apologies and understood.
> 
> Matthew
> 

Re: "infinite" gethostbyname(3)

[Ted Unangst]

Martin Pieuchot wrote:
> When my machine doesn't get a reply from a DNS server, generally the
> wifi router of the place where I'm drinking coffee, applications sit
> in gethostbyname(3) "indefinitely".  At least too long for me to wait
> and I end up killing the app.

We used to add an entry for the machine's hostname to /etc/hosts, but this
lead to other problems and was removed some years ago I believe.

Personally, I think it's a likely bug for software to resolve local hostname.
You already know the hostname, it's just gethostname(), and if you really need
to know the IP, it's in ifconfig, etc., but there's no reason to believe
there's only one IP or that other machines will know that this system has this
name.

Re: panic on vmctl start

[Ted Unangst]

Klemens Nanni wrote:
> Surprisingly simple, the last commit in that range broke it:
> 
>   revision 1.238
>   date: 2019/04/18 18:51:34;  author: mlarkin;
>   jMpas4GuYFG5;
>   vmm(4): whitespace fix
> 
> Reverting the first hunk of this commit fixes `vmctl start vpn' for me.
> 
> Feedback? OK?

obviously not intended. ok.

> 
> Index: arch/amd64/amd64/vmm.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/vmm.c,v
> retrieving revision 1.238
> diff -u -p -r1.238 vmm.c
> --- arch/amd64/amd64/vmm.c18 Apr 2019 18:51:34 -  1.238
> +++ arch/amd64/amd64/vmm.c20 Apr 2019 22:56:37 -
> @@ -40,7 +40,7 @@
>  
>  #include 
>  
> -#define VMM_DEBUG
> +/* #define VMM_DEBUG */
>  
>  void *l1tf_flush_region;
>  
> 

Re: Cannot set locale categories independently with POSIX 2008 locales

[Ted Unangst]

Karl Williamson wrote:
> On 3/28/19 8:03 AM, Ingo Schwarze wrote:
> >It is unspecified whether the locale object pointed to by base
> >shall be modified, or freed and a new locale object created.
> 
> I can see how you might be able to argue for your interpretation.  I 
> believe the wording in the spec is poor in this case (and it isn't the 
> only such place).  I, and every other implementer takes the above text 
> to mean, that it's up to the implementation as to how to combine 'base' 
> with the new locale specified by the other parameters.  'base' can be 
> modified and returned, or 'base' can be freed with some new locale which 
> is the combination of 'base' and the other parameters.  I don't take 
> that wording to mean that 'base' can be irrelevant.  That can't be the 
> intent, as that would mean wildly unportable code, and no way for the 
> program to specify an update to a category in isolation from the others. 

I would agree.

> > In any case, in the commit message, do not call it a "bug fix",
> > describe it as a change for compatibility with other systems.
> > 
> > Ted, feel free to either commit this version or tell me to commit.

Your version is good to commit. If you like, you may call it a workaround for a
specification bug that permitted the current behavior. :)

Re: Cannot set locale categories independently with POSIX 2008 locales

[Ted Unangst]

Karl Williamson wrote:
> > This should fix things.
> 
> Does it work if 'oldloc' is 0? a legal value

Nope. Good catch.


Index: newlocale.c
===
RCS file: /home/cvs/src/lib/libc/locale/newlocale.c,v
retrieving revision 1.1
diff -u -p -r1.1 newlocale.c
--- newlocale.c 5 Sep 2017 03:16:13 -   1.1
+++ newlocale.c 27 Mar 2019 22:01:12 -
@@ -22,8 +22,7 @@
 #include "rune.h"
 
 locale_t
-newlocale(int mask, const char *locname,
-locale_t oldloc __attribute__((__unused__)))
+newlocale(int mask, const char *locname, locale_t oldloc)
 {
int  ic, flag;
 
@@ -45,7 +44,7 @@ newlocale(int mask, const char *locname,
 
/* Only character encoding has thread-specific effects. */
if ((mask & LC_CTYPE_MASK) == 0)
-   return _LOCALE_C;
+   return oldloc ? oldloc : _LOCALE_C;
 
/* The following may initialize UTF-8 for later use. */
if ((locname = _get_locname(LC_CTYPE, locname)) == NULL) {

Re: Cannot set locale categories independently with POSIX 2008 locales

[Ted Unangst]

Karl Williamson wrote:
> This has been reported from multiple sources, and we at Perl 5 have 
> diagnosed the problem
> 
> If LC_CTYPE is set to C.UTF-8, it is not possible to set any other 
> category independently to either C or C.UTF-8 without inadvertently 
> setting LC_CTYPE back to C.  The attached program demonstrates the problem.

Thanks for a very thorough report. I believe your guesses about the
implementation were quite accurate. :)

This should fix things.

Index: newlocale.c
===
RCS file: /home/cvs/src/lib/libc/locale/newlocale.c,v
retrieving revision 1.1
diff -u -p -r1.1 newlocale.c
--- newlocale.c 5 Sep 2017 03:16:13 -   1.1
+++ newlocale.c 27 Mar 2019 06:25:01 -
@@ -22,8 +22,7 @@
 #include "rune.h"
 
 locale_t
-newlocale(int mask, const char *locname,
-locale_t oldloc __attribute__((__unused__)))
+newlocale(int mask, const char *locname, locale_t oldloc)
 {
int  ic, flag;
 
@@ -45,7 +44,7 @@ newlocale(int mask, const char *locname,
 
/* Only character encoding has thread-specific effects. */
if ((mask & LC_CTYPE_MASK) == 0)
-   return _LOCALE_C;
+   return oldloc;
 
/* The following may initialize UTF-8 for later use. */
if ((locname = _get_locname(LC_CTYPE, locname)) == NULL) {

Re: ping issue with rdomains

[Ted Unangst]

Claudio Jeker wrote:
> Ping is a bit of a special case since it runs with user _ping when started
> as root. So by the time the SO_RTABLE is issued it does not have the privs
> to do it. The ping -V option only works when used in rdomain 0.

Maybe we can drop privs a little later if we started running as root?
Just after getopt, which lets the setsockopt work, but before we do anything
dangerous.

Index: ping.c
===
RCS file: /home/cvs/src/sbin/ping/ping.c,v
retrieving revision 1.234
diff -u -p -r1.234 ping.c
--- ping.c  13 Nov 2018 14:30:36 -  1.234
+++ ping.c  19 Mar 2019 03:07:27 -
@@ -283,9 +283,9 @@ main(int argc, char *argv[])
uid = getuid();
gid = getgid();
}
-   if (setgroups(1, ) ||
+   if (ouid && (setgroups(1, ) ||
setresgid(gid, gid, gid) ||
-   setresuid(uid, uid, uid))
+   setresuid(uid, uid, uid)))
err(1, "unable to revoke privs");
 
preload = 0;
@@ -428,6 +428,11 @@ main(int argc, char *argv[])
usage();
}
}
+
+   if (ouid == 0 && (setgroups(1, ) ||
+   setresgid(gid, gid, gid) ||
+   setresuid(uid, uid, uid)))
+   err(1, "unable to revoke privs");
 
argc -= optind;
argv += optind;

confusing install error with no net

[Ted Unangst]

Was performing an upgrade, got to the part about asking where the sets are.
Specified http. https didn't work (just an internal httpd server, that's
normal.) Say yes, try http. Get the error that no sets were found. Took me a
few retries, guessing that maybe I typed the path wrong, but the problem was I
didn't have any network interfaces configured.

I'm not sure what exactly could be improved. Maybe just a better error
message? "Found no openbsd sets" implies it was able to connect and look.

Or maybe get fancy and if ifconfig reports no addresses print a warning?

Re: pthread_rwlock deadlock

[Ted Unangst]

Sebastien Marie wrote:
> 
> does it makes sens to call __sflush() instead of fflush() in vdprintf() ?
> 
> the FILE variable used by vdprintf() is "home made" on the stack, using
> a buffer on the stack too. And as fflush() only enclose __sflush()
> with FILE locking, I don't see the gain to use fflush() here.

This makes sense. ok me too.

Re: pthread_rwlock deadlock

[Ted Unangst]

Visa Hankala wrote:
> On Sat, Mar 02, 2019 at 10:29:07AM +0100, Sebastien Marie wrote:
> > I am experiencing dead-lock with the new futex based rwlock
> > implementation commited few days ago.
> 
> The problem happens if a read-write lock has been read-locked and
> there are multiple writers waiting. The unlock routine will clear the
> waiter flag and wake up a single waiter. If no new waiters emerge
> before the next unlock, no wakeup will be issued.
> 
> A simple fix is to wake all waiters, so that no wakeup is lost.
> That may cause a thundering herd effect with writers though. The
> implementation could encode the number of waiters in `rwlock->value',
> enabling more discreet wakeups. However, that needs more testing.
> 
> Does the following patch help?

This looks ok to me.

> 
> Index: rthread_rwlock.c
> ===
> RCS file: src/lib/librthread/rthread_rwlock.c,v
> retrieving revision 1.12
> diff -u -p -r1.12 rthread_rwlock.c
> --- rthread_rwlock.c  13 Feb 2019 13:22:14 -  1.12
> +++ rthread_rwlock.c  2 Mar 2019 13:35:31 -
> @@ -273,7 +273,7 @@ pthread_rwlock_unlock(pthread_rwlock_t *
>   } while (atomic_cas_uint(>value, val, new) != val);
>  
>   if (new == UNLOCKED && (val & WAITING))
> - _wake(>value, COUNT(val));
> + _wake(>value, INT_MAX);
>  
>   return (0);
>  }
> 

Re: pthread_rwlock deadlock

[Ted Unangst]

Visa Hankala wrote:
> On Sat, Mar 02, 2019 at 04:37:04PM +0100, Sebastien Marie wrote:
> > Thread 1 (thread 469200):
> > #0  sched_yield () at -:3
> > #1  0x0a8c0609d9c5 in _libc__spinlock (lock=Variable "lock" is not 
> > available.) at /usr/src/lib/libc/thread/rthread.c:50
> > #2  0x0a8c060702be in _thread_flockfile (fp=0x7f7cfaa8) at 
> > /usr/src/lib/libc/thread/rthread_file.c:180
> > #3  0x0a8c0609e11a in _libc_fflush (fp=0x7f7cfaa8) at 
> > /usr/src/lib/libc/stdio/fflush.c:46
> > #4  0x0a8c0606c89a in _libc_vdprintf (fd=Variable "fd" is not 
> > available.) at /usr/src/lib/libc/stdio/vdprintf.c:72
> > #5  0x0a8c060a7f63 in _libc__rthread_debug (level=Variable "level" is 
> > not available.) at /usr/src/lib/libc/thread/rthread_debug.c:23
> > #6  0x0a8c060410c5 in _rthread_mutex_timedlock (mutexp=Variable 
> > "mutexp" is not available.) at /usr/src/lib/libc/thread/rthread_mutex.c:163
> > #7  0x0a8c060bc482 in malloc (size=56) at 
> > /usr/src/lib/libc/stdlib/malloc.c:1253
> > #8  0x0a8c060703e4 in _thread_flockfile (fp=0x7f7d02b8) at 
> > /usr/src/lib/libc/thread/rthread_file.c:156
> > #9  0x0a8c0609e11a in _libc_fflush (fp=0x7f7d02b8) at 
> > /usr/src/lib/libc/stdio/fflush.c:46
> > #10 0x0a8c0606c89a in _libc_vdprintf (fd=Variable "fd" is not 
> > available.) at /usr/src/lib/libc/stdio/vdprintf.c:72
> > #11 0x0a8c060a7f63 in _libc__rthread_debug (level=Variable "level" is 
> > not available.) at /usr/src/lib/libc/thread/rthread_debug.c:23
> > #12 0x0a8c3c2792b6 in _rthread_reaper () at 
> > /data/openbsd/src/lib/librthread/rthread.c:260
> > #13 0x0a8c3c279229 in pthread_join (thread=Variable "thread" is not 
> > available.) at /data/openbsd/src/lib/librthread/rthread.c:319
> > #14 0x0a8993d1a705 in main (argc=1, argv=0x7f7d0ab8) at test.c:86
> 
> This does not look good. The thread is recursing with hash_lock of
> rthread_file.c. Apparently triggered by the debug output routine.
> 

Yeah, I think thread_debug needs to use snprintf and write the message itself.

Re: OpenBSD 6.4 doesn't boot on 486 class processor anymore

[Ted Unangst]

Philip Guenther wrote:
> The problem is that ucode_load() in sys/arch/i386/stand/libsa/exec_i386.c 
> uses CPUID() without checking whether the cpuid instruction is supported.  
> There are currently three places in sys/arch/i386/stand/libsa which make 
> that check: cpuprobe.c, machdep.c, and random_i386.S. ucode_load() could 
> copy the chunk from machdep.c...or someone could add a global and do the 
> check once, early...

Or we make cpuid a required feature?

Re: ure not detected with ramdisk

[Ted Unangst]

Theo de Raadt wrote:
> Ted Unangst  wrote:
> 
> > Thinkpad X1 2015. I have a ure that works fine with normal kernels but was 
> > not
> > detected when using the ramdisk.
> 
> 'cause it isn't in the config??
> 
> So the process is you add it, build a ramdisk, report the size increase,
> and a few of us mull what that number means for future growth we might
> need 'cause ramdisks can be quite a bit bigger than GENERIC easily since
> the install filesystem is also in there.

It is in the config. I don't know why it doesn't appear.

ure not detected with ramdisk

[Ted Unangst]

Thinkpad X1 2015. I have a ure that works fine with normal kernels but was not
detected when using the ramdisk.

cat /tmp/dmesg  | egrep openbsd\|^uhub\|^ure 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 
addr 1
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
uhub2 at uhub1 port 1 configuration 1 interface 0 "vendor 0x8087 product 
0x8001" rev 2.00/0.03 addr 2
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 
addr 1
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
ure0 at uhub0 port 13 configuration 1 interface 0 "Realtek USB 10/100/1000 LAN" 
rev 3.00/30.00 addr 5
ure0: ver 5c10, address 9c:eb:e8:22:66:f3
uhub2 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 
2.00/0.03 addr 2

OpenBSD 6.4-current (RAMDISK_CD) #622: Tue Jan 29 19:15:56 MST 2019
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 8238301184 (7856MB)
avail mem = 7984648192 (7614MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (66 entries)
bios0: vendor LENOVO version "N14ET28W (1.06 )" date 03/12/2015
bios0: LENOVO 20BSCTO1WW
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT 
SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM BATB FPDT UEFI DMAR
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, 2195.29 MHz, 06-3d-04
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 3 (EXP1)
acpiprt3 at acpi0: bus 4 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus -1 (EXP6)
acpicpu at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpitz at acpi0 not configured
"PNP0C0D" at acpi0 not configured
"PNP0C0E" at acpi0 not configured
"PNP0A08" at acpi0 not configured
"PNP0B00" at acpi0 not configured
"PNP0C0A" at acpi0 not configured
"ACPI0003" at acpi0 not configured
"LEN0068" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT340F" at acpi0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 5G Host" rev 0x09
vga1 at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 0x09
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
"Intel Core 5G HD Audio" rev 0x09 at pci0 dev 3 function 0 not configured
xhci0 at pci0 dev 20 function 0 "Intel 9 Series xHCI" rev 0x03: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 
addr 1
"Intel 9 Series MEI" rev 0x03 at pci0 dev 22 function 0 not configured
em0 at pci0 dev 25 function 0 "Intel I218-LM" rev 0x03: msi, address 
54:ee:75:3c:17:cb
"Intel 9 Series HD Audio" rev 0x03 at pci0 dev 27 function 0 not configured
ppb0 at pci0 dev 28 function 0 "Intel 9 Series PCIE" rev 0xe3: msi
pci1 at ppb0 bus 3
ppb1 at pci0 dev 28 function 1 "Intel 9 Series PCIE" rev 0xe3: msi
pci2 at ppb1 bus 4
iwm0 at pci2 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev 0x59, msi
ehci0 at pci0 dev 29 function 0 "Intel 9 Series USB" rev 0x03: apic 2 int 23
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
"Intel 9 Series LPC" rev 0x03 at pci0 dev 31 function 0 not configured
ahci0 at pci0 dev 31 function 2 "Intel 9 Series AHCI" rev 0x03: msi, AHCI 1.3
ahci0: port 3: 6.0Gb/s
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 3 lun 0:  SCSI3 0/direct fixed 
naa.5002538d4024a2df
sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin
"Intel 9 Series SMBus" rev 0x03 at pci0 dev 31 function 3 not configured
"Intel 9 Series Thermal" rev 0x03 at pci0 dev 31 function 6 not configured
isa0 at mainbus0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay1
"vendor 0x138a product 0x0017" rev 1.10/0.78 addr 2 at 

iwm put itself down

[Ted Unangst]

I'm using a very bad wifi network, which causes iwm much sadness, but this
particular error was new and unexpected.

Suddenly ping announces the network is down.
ping: sendmsg: Network is down
ping: wrote ox.tedunangst.com 64 chars, ret=-1

Sure enough, ifconfig says no network. And now comes the strange part. I run
ifconfig scan and get an error.

ifconfig: SIOCG80211ALLNODES: Network is down

Maybe if I had run ifconfig down that would be sensible, but I didn't. My
expectation is that if the interface is up, it will stay up, even if it
disconnects from the network.

The problem was resolved by running ifconfig up manually.

Re: kern.clockrate documentation patch

[Ted Unangst]

Amit Kulkarni wrote:
> Hi,
> 
> I wanted to know the value of tick, went to man.openbsd.org, and got 
> https://man.openbsd.org/tick
> 
> While the answer provided on this page below is accurate, IMHO it is not 
> useful. I had to do a grep on "tick" for the kern.clockrate sysctl. Something 
> like the below would be better.
> 
> Thanks
> 
> diff --git man9/hz.9 man9/hz.9
> index a319266e518..ac5e8f60850 100644
> --- man9/hz.9
> +++ man9/hz.9
> @@ -79,11 +79,11 @@ may be used to skew this increment, but by no more
>  than ten times
>  .Va tickadj .
>  .Pp
> -Those systems variables are available as a struct clockinfo from
> -.Xr sysctl 2 .
> +These system variables are available as kern.clockrate from
> +.Xr sysctl 8 .

This is meant to be programmer documentation, so I think it makes sense to
keep it referring to sysctl.2. However, it's a good point that you shouldn't
have to grep for clockinfo.

If we mention KERN_CLOCKRATE that makes searching faster and should allow
users to figure out kern.clockrate.


Index: hz.9
===
RCS file: /cvs/src/share/man/man9/hz.9,v
retrieving revision 1.8
diff -u -p -r1.8 hz.9
--- hz.912 Jan 2018 04:36:45 -  1.8
+++ hz.96 Jan 2019 19:07:27 -
@@ -79,7 +79,9 @@ may be used to skew this increment, but 
 than ten times
 .Va tickadj .
 .Pp
-Those systems variables are available as a struct clockinfo from
+These system variables are available by reading
+.Va KERN_CLOCKRATE
+from
 .Xr sysctl 2 .
 .Sh SEE ALSO
 .Xr adjtime 2 ,

httpd sends too many 408s

[Ted Unangst]

HTTP/1.1 connections stay alive by default, unless the client or server
indicates it will close with the Connection: close header. After a timeout,
the connection typically closes anyway.

httpd in this case sends back a 408 Request Timeout response. This is unusual.

I did not exhaustively study the RFCs, but 408 seems primarily for indicating
that the client is sending the request too slowly. If the server has already
finished the request, then 408 would not apply.

Other servers don't seem to send 408 either. When they have decided that a
keepalive connection is too old, they simply close it.

In my case, I'm not running httpd server, but the go http client complains
about receiving unexpected data.

Re: rc(8) ignores last line without newline of *.conf

[Ted Unangst]

George Koehler wrote:
>   stripcom() in /etc/rc uses `while read _line ; do ... done`
> to read these files, but `read _line` exits 1 when the last line is
> without a newline.  This behavior in sh and ksh is consistent with
> bash, dash, ksh93, and yash:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206

3.206 Line
A sequence of zero or more non-  characters plus a terminating
 character.

A line without a newline is not a line.

Re: fread() on unbuffered FILE doesn't set feof flag

[Ted Unangst]

Todd C. Miller wrote:
> 
> After thinking about this a bit more I believe it best to just use
> the existing FILE * and swap in the buffer temporarily.  There's
> no need to store the value of the old buffer; since we are unbuffered
> it can only point to _nbuf.

This is neat.

Re: fread() on unbuffered FILE doesn't set feof flag

[Ted Unangst]

Ted Unangst wrote:
> Todd C. Miller wrote:
> > On Wed, 12 Dec 2018 13:08:07 -0500, "Ted Unangst" wrote:
> > 
> > > i don't want to go too far down the legacy rabbit hole, just float nicely
> > > above it.
> > 
> > Which is exactly how we got to this point.  What else is missing
> > and how many years will it take before someone notices?  Is it
> > really safe to completely ignore the stdio flags?
> 
> One missed feature every five years doesn't sound all that bad. :)
> 
> But sure, if we want to revert and regress before putting it back, ok.

I went with a simpler #if 0 approach because I think it will make it easier to
track the fixes.

ok?

Index: fread.c
===
RCS file: /cvs/src/lib/libc/stdio/fread.c,v
retrieving revision 1.15
diff -u -p -r1.15 fread.c
--- fread.c 21 Sep 2016 04:38:56 -  1.15
+++ fread.c 12 Dec 2018 18:50:03 -
@@ -69,6 +69,7 @@ fread(void *buf, size_t size, size_t cou
total = resid;
p = buf;
 
+#if 0
if ((fp->_flags & __SNBF) != 0) {
/*
 * We know if we're unbuffered that our buffer is empty, so
@@ -82,6 +83,7 @@ fread(void *buf, size_t size, size_t cou
FUNLOCKFILE(fp);
return ((total - resid) / size);
}
+#endif
 
while (resid > (r = fp->_r)) {
(void)memcpy(p, fp->_p, r);

Re: fread() on unbuffered FILE doesn't set feof flag

[Ted Unangst]

Todd C. Miller wrote:
> On Wed, 12 Dec 2018 13:08:07 -0500, "Ted Unangst" wrote:
> 
> > i don't want to go too far down the legacy rabbit hole, just float nicely
> > above it.
> 
> Which is exactly how we got to this point.  What else is missing
> and how many years will it take before someone notices?  Is it
> really safe to completely ignore the stdio flags?

One missed feature every five years doesn't sound all that bad. :)

But sure, if we want to revert and regress before putting it back, ok.

Re: fread() on unbuffered FILE doesn't set feof flag

[Ted Unangst]

Todd C. Miller wrote:
> On Wed, 12 Dec 2018 08:59:25 +0100, Sebastien Marie wrote:
> 
> > The approch is to directly set __SEOF or __SERR. It is more simple than
> > trying to reuse __srefill().
> 
> My concern is that __srefill() does more than just that.  In particular,
> it has the following:
> 
> /*
>  * Before reading from a line buffered or unbuffered file,
>  * flush all line buffered output files, per the ANSI C
>  * standard.
>  */
> 
> However, a quick scan of the ISO C99 spec didn't reveal any such
> requirement.  Perhaps someone else better versed in standardese
> knows what the comment is referring to.
> 
> I also worry about the lack of stdio initialization (__sinit()) and
> logic for switching from reading to writing.

isn't the point to avoid all this stuff because it's not necessary? srefill()
has to be one of the worst functions around. it does a dozen different things,
so whenever something is supposed to happen a call to srefill is inserted, but
nobody knows what's supposed to happen *right here right now*. like how do we
get here without previously calling sinit? srefill seems like a very strange
place to stash the init call.

i don't want to go too far down the legacy rabbit hole, just float nicely
above it.

Re: libGL error: ...

[Ted Unangst]

Roderick wrote:
> 
> libGL error: Version 4 or later of flush extension not found
> libGL error: failed to load driver i915

This error also occurs on an HP mini 110. It appears cosmetic. glxgears still
runs, fast enough, and firefox runs as well, somewhat less fast.

dmesg below. it's GM45.

inteldrm0 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03

OpenBSD 6.4 (GENERIC.MP) #943: Thu Oct 11 13:51:32 MDT 2018
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem  = 2138259456 (2039MB)
avail mem = 2084151296 (1987MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 09/02/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.4 @ 
0xfc890 (18 entries)
bios0: vendor Hewlett-Packard version "308F0 Ver. F.16" date 09/02/2009
bios0: Hewlett-Packard HP Mini 110-1100
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET ASF! SSDT
acpi0: wakeup devices P0P2(S4) P0P1(S4) LAN2(S3) USB0(S3) USB3(S3) EUSB(S3) 
MC97(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz, 
06-1c-02
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,NXE,LAHF,PERF,SENSOR,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class) 1.60 GHz, 
06-1c-02
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,NXE,LAHF,PERF,SENSOR,MELTDOWN
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P1)
acpiprt2 at acpi0: bus 2 (P0P5)
acpiprt3 at acpi0: bus -1 (P0P6)
acpiprt4 at acpi0: bus -1 (P0P7)
acpiprt5 at acpi0: bus -1 (P0P8)
acpiprt6 at acpi0: bus -1 (P0P9)
acpiec0 at acpi0
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 
mwait.1), PSS
acpitz0 at acpi0: critical temperature is 100 degC
acpicmos0 at acpi0
"SYN1E0C" at acpi0 not configured
acpibat0 at acpi0: BAT1 model "Primary" serial   type LION oem "Hewlett-Packard"
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
"PNP0C14" at acpi0 not configured
acpibtn2 at acpi0: PWRB
acpivideo0 at acpi0: IGD_
acpivout0 at acpivideo0: LCD_
bios0: ROM list: 0xc/0xec00!
cpu0: Enhanced SpeedStep 1597 MHz: speeds: 1600, 1333, 1067, 800 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82945GME Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82945GME Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 2 int 16
inteldrm0: 1024x600, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 82945GM Video" rev 0x03 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: IDT 92HD81B1X
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 2 int 16
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 2 int 17
pci2 at ppb1 bus 2
alc0 at pci2 dev 0 function 0 "Attansic Technology L2C" rev 0xc0: msi, address 
00:26:55:c6:a6:2b
atphy0 at alc0 phy 0: F1 10/100/1000 PHY, rev. 11
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 2 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 2 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 2 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 2 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
ppb2 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
pci3 at ppb2 bus 3
ichpcib0 at pci0 dev 31 function 0 "Intel 82801GBM LPC" rev 0x02: PM disabled
ahci0 at pci0 dev 31 function 2 "Intel 82801GBM AHCI" rev 0x02: msi, AHCI 1.1
ahci0: port 0: 1.5Gb/s
ahci0: PHY offline on port 2
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.50e043efec9f
sd0: 152627MB, 512 bytes/sector, 

Re: fread() on unbuffered FILE doesn't set feof flag

[Ted Unangst]

Sebastien Marie wrote:
> When looking at fread(3) code in libc, I found that we doesn't set
> __SEOF when the FILE is unbuffered.
> 
> src/lib/libc/stdio/fread.c
> 72  if ((fp->_flags & __SNBF) != 0) {
> 73  /*
> 74   * We know if we're unbuffered that our buffer is 
> empty, so
> 75   * we can just read directly. This is much faster 
> than the
> 76   * loop below which will perform a series of one byte 
> reads.
> 77   */
> 78  while (resid > 0 && (r = (*fp->_read)(fp->_cookie, p, 
> resid)) > 0) {
> 79  p += r;
> 80  resid -= r;
> 81  }
> 82  FUNLOCKFILE(fp);
> 83  return ((total - resid) / size);
> 84  }


> Is it a bug to not set the __SEOF flag or it is expected for unbuffered
> FILE ?

seems like a bug. the code above was added more recently, and must have missed
this case.

Re: Thinkpad X1 reproducible suspend panic

[Ted Unangst]

Edd Barrett wrote:
> I used a USB drive so that I wouldn't trash my everyday filesystems by
> constant dirty shutdowns. However, it seems essential for reproduction.
> If I boot a recent snap off my SSD, this bug does not manifest (but

this will never work. USB devices are ejected during suspend. there may be
something else going on, but if it can only be reproduced in a known bad
config, it's not worth pursuing.

idle threads say 100%

[Ted Unangst]

I know there have been some changes in this area, but this seems like a
remaining bug.

Run top. Press S to show system processes. Observe idle1 and idle3 (the
hyperthreaded idles) stuck at 100%. With 0:00 time.

Now if you switch hw.smt=1 the 100% slowly ticks down, but the time
immediately jumps up to many hours.

Just a peculiarity I noticed. Perhaps there's some way to consolidate special
cases?

Re: bug in master src/lib/libc/hash/siphash.c

[Ted Unangst]

Mark Karpilovskij wrote:
> If only a single call to SipHash_Update is performed or if the size of
> processed data is a multiple of sizeof(ctx->buf), this bug does nothing.
> However when we performed several updates of various lengths, the data
> written to ctx->buf were too long and the call to memcpy overwrote other
> data, which led to various unexpected behavior.

I concur. Here's a diff for review.

Index: siphash.c
===
RCS file: /cvs/src/lib/libc/hash/siphash.c,v
retrieving revision 1.6
diff -u -p -r1.6 siphash.c
--- siphash.c   12 Apr 2017 17:41:49 -  1.6
+++ siphash.c   22 Dec 2017 01:13:59 -
@@ -104,7 +104,7 @@ SipHash_Update(SIPHASH_CTX *ctx, int rc,
}
 
if (len > 0)
-   memcpy(>buf[used], ptr, len);
+   memcpy(ctx->buf, ptr, len);
 }
 DEF_WEAK(SipHash_Update);
 

ftp proxies and redirects

[Ted Unangst]

I believe there's a bug with ftp and redirects when using a proxy. ftp seems
to add the redirect URL to the proxy host, fetching http://proxy/new-url
instead of http://orighost/new-url. I'm not certain this isn't a server or
proxy bug, in part because I'm not certain who's supposed to say what or how
it's interpreted, but my first guess is to blame ftp. :) In the same setup,
chrome redirects to http://orighost/new-url.

Re: config(8) elf handling

[Ted Unangst]

Philip Guenther wrote:
> On Wed, 13 Sep 2017, Miod Vallat wrote:
> > 
> > > Forcing uextraloc into .data via
> > > int uextraloc __attribute__ ((section(".data"))) = 0;
> > > avoids the crashes.
> > 
> > Regardless of this bug, the in-tree gcc was modified to default to put
> > explicitly zero initialized data in .data rather than .bss, i.e. default
> > to -fno-zero-initialized-in-bss.
> > 
> > It might be wise to make the default configuration of clang follow this
> > behaviour as well.
> 
> Anyone recall the issues that it was originally changed to fix?
> 
> If it was the kernel config stuff, maybe we should just pass the option 
> explicitly in the kernel Makefiles and not push it on all of userland.

oh, hi, that was me! yes, it was for kernel config specifically, and binary
hacking in general. the old ABI, from vaxen of yore, would leave things in
data, so that's where we wanted them to remain. but time moves on i guess.

Re: Suspend-to-full-encrypted-disk is broken (by KARL?)

[Ted Unangst]

Natasha Kerensikova wrote:
> on Thursday 20 July 2017 at 21:45, YASUOKA Masahiko wrote:
> > On Tue, 18 Jul 2017 15:48:48 -0600
> > "Theo de Raadt"  wrote:
> > > The changes introduced into the bootloader are largely correct.  They
> > > make the right decisions.  They just don't make them at the right
> > > points in time.  The IO operations should be moved further forward, to
> > > after the key operations.
> > > 
> > > Havinge done it this way, yasuoka and I were able to create a workable
> > > model, but the operations need to be moved forward.
> > > 
> > > Someone want to dive in?
> > 
> > The diff is to support selecting bsd.booted for FED.
> 
> I have been happily using the fixed bootloader, but I noticed a few times
> that I still had unhibernating failures due to incorrect kernel.  After
> further investigation, I think that it correctly loads /bsd.booted when
> I enter the correct passphrase on the first try, which happens quite
> often thanks to muscle memory.  However when I enter a wrong passphrase,
> and subsequently enter the correct one on the second prompt, the
> bootloader doesn't seem to detect the hibernation and loads /bsd, which
> cannot unhibernate.

After a failed password attempt, when you press enter, I think that picks the
default again, which is "bsd". If you type bsd.booted I bet it works. The
order of the tests and decisions is still a little vague.

ssh-keygen -l -v -F

[Ted Unangst]

The man page says using -l to print the fingerprint I can add a -v to get the
pretty art, but this doesn't work with -F. It just prints the ugly base64
gibberish.

Re: asus x205ta keyboard issue

[Ted Unangst]

michele.cu...@gmail.com wrote:
> >Synopsis:iic keyboard sometimes reapeat key press
>   When the problem happens, on dmesg I see messages like this:
> 
>   dwiic1: timed out reading remaining 13
> 
>   Any idea what's happening?

keyboard controllers are surprisingly complex. or perhaps quirky is a better
word. it took 20 years to get the pckbd driver working. and now we get to
start all over with iic controllers.

that's kind of a meta point, but the idea is until such machines become
common, there's probably going to be a few issues.

Re: OpenBSD guest hangs in vmd on -current host

[Ted Unangst]

Mike Larkin wrote:
> On Tue, Jul 18, 2017 at 09:36:12PM -0700, Max Parmer wrote:
> > 
> > >Synopsis:  OpenBSD guest hangs in vmd on -current host
> > >Category:  system
> > >Environment:
> > System  : OpenBSD 6.1
> > Details : OpenBSD 6.1-current (GENERIC.MP) #99: Mon Jul 17 16:53:49 
> > MDT 2017
> >  
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > When running an OpenBSD guest under vmd after a short time the guest 
> > will hang, the
> > corresponding vmd process will hit and stay at 99.9% CPU usage.
> > 
> > Examination with ktrace shows a pattern similar to the past reports 
> > from tedu@[1] and
> > Gregor Best[2] with the process spinning on kevent and gettime, excerpt:
> >  15607 vmd  RET   kevent 1  
> >  15607 vmd  CALL  clock_gettime(CLOCK_MONOTONIC,0x121dae4dbd20) 
> >  
> >  15607 vmd  STRU  struct timespec { 20180.643241450 }   
> >  
> >  15607 vmd  RET   clock_gettime 0   
> >  15607 vmd  CALL  kevent(5,0,0,0x121da5f22000,64,0x121dae4dbcf0)
> >  
> >  15607 vmd  STRU  struct timespec { 0.002255000 }
> > 
> > I first encountered this issue on the snapshot from Jul 15th and was 
> > able to reproduce
> > several times under that snapshot and the subsequent snapshots from the 
> > 16th and 17th.
> > 
> > Typically the VM will run normally for a short time before hanging, and 
> > it seems to
> > occur both with /bsd and /bsd.rd. Typing seems to trigger it.
> > 
> 
> I bet I botched this with the serial port "improvement" done last month. I'll
> take a look tonight, thanks for the info.

to perhaps give you a hint, it looks, from the outside, like there's a byte to
be read, but vmd is in the "don't want bytes now" state, but has gotten out of
sync with libevent, which keeps calling the byte ready function, which keeps
doing nothing. but that's blind stabbing.

Re: OpenBSD guest hangs in vmd on -current host

[Ted Unangst]

Max Parmer wrote:
> 
> >Synopsis:OpenBSD guest hangs in vmd on -current host
> >Category:system
> >Environment:
>   System  : OpenBSD 6.1
>   Details : OpenBSD 6.1-current (GENERIC.MP) #99: Mon Jul 17 16:53:49 
> MDT 2017
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   When running an OpenBSD guest under vmd after a short time the guest 
> will hang, the
>   corresponding vmd process will hit and stay at 99.9% CPU usage.
>   
>   Examination with ktrace shows a pattern similar to the past reports 
> from tedu@[1] and
>   Gregor Best[2] with the process spinning on kevent and gettime, excerpt:
>15607 vmd  RET   kevent 1  
>15607 vmd  CALL  clock_gettime(CLOCK_MONOTONIC,0x121dae4dbd20) 
>  
>15607 vmd  STRU  struct timespec { 20180.643241450 }   
>  
>15607 vmd  RET   clock_gettime 0   
>15607 vmd  CALL  kevent(5,0,0,0x121da5f22000,64,0x121dae4dbcf0)
>  
>15607 vmd  STRU  struct timespec { 0.002255000 }
> 
>   I first encountered this issue on the snapshot from Jul 15th and was 
> able to reproduce
>   several times under that snapshot and the subsequent snapshots from the 
> 16th and 17th.

i didn't dig into vmd to see where it's spinning, but if you run vmd with env
EVENT_NOKQUEUE=1 then I haven't observed the problem.

Re: missing "struct socket;" in netinet/ip_var.h prevents compiling kernel without MROUTING option

[Ted Unangst]

Nick Briggs wrote:
>  because netinet/ip_var.h, which it includes, depends on
>#ifdef MROUTING
>extern struct socket *ip_mrouter[]; /* multicast routing daemon */
>#endif
> to get a declaration of struct socket outside of any parameter lists.

I think this is a better fix. Two parts.

1. pfkeyv2_parsemessage.c doesn't even need this header. remove it.

2. to prevent this from happening again, move the forward declaration in
ip_var.h to the end, so that it will fail regardless of compile options. i
think this is better than deliberately exporting another type here.

tested with and without MROUTING set.

Index: net/pfkeyv2_parsemessage.c
===
RCS file: /cvs/src/sys/net/pfkeyv2_parsemessage.c,v
retrieving revision 1.52
diff -u -p -r1.52 pfkeyv2_parsemessage.c
--- net/pfkeyv2_parsemessage.c  26 Jun 2017 09:17:55 -  1.52
+++ net/pfkeyv2_parsemessage.c  14 Jul 2017 02:35:13 -
@@ -76,7 +76,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #if NPF > 0
Index: netinet/ip_var.h
===
RCS file: /cvs/src/sys/netinet/ip_var.h,v
retrieving revision 1.79
diff -u -p -r1.79 ip_var.h
--- netinet/ip_var.h26 Jun 2017 19:06:12 -  1.79
+++ netinet/ip_var.h14 Jul 2017 02:34:17 -
@@ -193,9 +193,6 @@ struct ipq {
 extern struct ipstat ipstat;
 extern LIST_HEAD(ipqhead, ipq) ipq;/* ip reass. queue */
 extern int ip_defttl;  /* default IP ttl */
-#ifdef MROUTING
-extern struct socket *ip_mrouter[];/* multicast routing daemon */
-#endif
 
 #define IPMTUDISCTIMEOUT (10 * 60) /* as per RFC 1191 */
 
@@ -259,6 +256,10 @@ int rip_output(struct mbuf *, struct so
 int rip_usrreq(struct socket *,
int, struct mbuf *, struct mbuf *, struct mbuf *, struct proc *);
 int rip_attach(struct socket *, int);
+
+#ifdef MROUTING
+extern struct socket *ip_mrouter[];/* multicast routing daemon */
+#endif
 
 #endif /* _KERNEL */
 #endif /* _NETINET_IP_VAR_H_ */

Re: canaries can cause malloc with a size of 0 to hang

[Ted Unangst]

Otto Moerbeek wrote:
> I think I found it: requested size is not recorded for malloc(0),
> bp->offset is not initialized in that case. Other code is carefull not to
> use ->offset for size == 0.
> OA
>   -Otto

OA from me. :)

> 
> Index: malloc.c
> ===
> RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
> retrieving revision 1.226
> diff -u -p -r1.226 malloc.c
> --- malloc.c  19 Jun 2017 03:06:26 -  1.226
> +++ malloc.c  7 Jul 2017 06:51:30 -
> @@ -1013,7 +1013,7 @@ malloc_bytes(struct dir_info *d, size_t 
>   /* Adjust to the real offset of that chunk */
>   k += (lp - bp->bits) * MALLOC_BITS;
>  
> - if (mopts.chunk_canaries)
> + if (mopts.chunk_canaries && size > 0)
>   bp->bits[bp->offset + k] = size;
>  
>   k <<= bp->shift;
> 

Re: panic: Stopped at kqueue_scan

[Ted Unangst]

Aaron Bieber wrote:
> For roughly a week I have been able to reliably produce panics on
> amd64 (virtual machine and physical machine) using disk IO heavy
> applications (gitea, syncthing).

these are also network applications, no? i think that's the io that causes
trouble.

Re: reorder_kernel requires writable /usr/share

[Ted Unangst]

Theo de Raadt wrote:
> Yes, but once again I don't know what this is trying to help.
> 
> Just you, I think.  Maybe someone else?
> 
> I am unsure if these 6-line chunks belong in /etc.  The configuration
> is way out of default.

Configuration creep. Start with six lines to support readonly /usr because "it
can't hurt". Next feature needs six more lines. Then six more lines. Now it
looks like readonly /usr is supported. Look at all these lines that make it
work!

Re: mandoc -Tlint and Mdocdate

[Ted Unangst]

Ingo Schwarze wrote:
> As there is no fully satisfactory option, i propose the patch below.
> It add the "-W portable" command line option, which is a variant of
> "-W style" hiding messages that only apply to base system manuals.

I'm not fond of the name portable. To me, this suggests it will check for
things which impede portability, but that's not really what it does. It may
have that effect in some cases, but more as an incidental effect.

Instead, I suggest shifting the names by one. Leave -W style as the portable
option, but introduce -W openbsd which performs the additional checks. Or
better, name it -W system, so as to be useful on netbsd, etc.

I think this matches the actual hierarchy in practice. There's errors and
warnings at the top. Then there's general style warnings. Then below that
there's the local system specific style guidelines. It's a matter of
perspective, but the portable warnings aren't subset of style, rather the
system warnings are a superset of style.

Re: httpd violates pledge with passworded private key

[Ted Unangst]

Joel Sing wrote:
> > tls_configure_keypair() -> return EWANTSPASSWORD -> application decides how
> > to proceed, possibly asking for password, calls
> > tls_configure_keypair_this_time_with_password().
> 
> I'm not sure that I'd consider that sane. We already have tls_load_file() for 
> this purpose, although admittedly the API there could probably be friendlier. 
> Do we really want tls_configure_keypair() to become "maybe encrypted, maybe 
> unencrypted"? I'm not convinced that we should really be making libtls expect 
> to be dealing with encrypted keys at that point.

oh, i think the current API is fine. tls_load_file is the function i was
proposing we add. :)

Re: httpd violates pledge with passworded private key

[Ted Unangst]

Jonathan Gray wrote:
> when using a server.key with a passphrase, ie


> ) at /usr/src/lib/libc/stdio/fopen.c:54
> #3  0x022b2d92d26f in open_console (ui=Variable "ui" is not available.
> ) at /usr/src/lib/libcrypto/ui/ui_openssl.c:304

> #6  0x022b2d9dc018 in PEM_def_callback
> ) at /usr/src/lib/libcrypto/pem/pem_lib.c:113

> #10 0x022b6ef43b62 in tls_configure_ssl_keypair

ugh, i think this is a bug in libtls. there should not be sneaky bullshit
console reading functions being called behind the scenes. this is, as
discovered, kind of surprising. and quite the layering violation, separation
of concerns, and all that.

a sane API would look something like this:

tls_configure_keypair() -> return EWANTSPASSWORD -> application decides how to
proceed, possibly asking for password, calls
tls_configure_keypair_this_time_with_password().

weird spin in vmd

[Ted Unangst]

ktrace shows we appear to be spinning on kevent and gettime. fd 7 is the tty.

Not sure what went wrong. Happened just after typing "root" at login. Never
got to password. Reboot, fsck, appears to work now.

_vmd vmd750337 /  182448  crw-rw-rw-rwptypt

 75033 vmd  CALL  clock_gettime(CLOCK_MONOTONIC,0x6cdf3156030)
 75033 vmd  STRU  struct timespec { 366729.439807068 }
 75033 vmd  RET   clock_gettime 0
 75033 vmd  CALL  kevent(0,0x6ce1a957800,0,0x6cd99f5c800,64,0x6cdf3156000)
 75033 vmd  STRU  struct timespec { 0.003247000 }
 75033 vmd  STRU  struct kevent { ident=7, filter=EVFILT_READ, 
flags=0x1, fflags=0<>, data=15, udata=0x6cb750a7638 }
 75033 vmd  RET   kevent 1
 75033 vmd  CALL  clock_gettime(CLOCK_MONOTONIC,0x6cdf3156030)
 75033 vmd  STRU  struct timespec { 366729.439816566 }
 75033 vmd  RET   clock_gettime 0
 75033 vmd  CALL  kevent(0,0x6ce1a957800,0,0x6cd99f5c800,64,0x6cdf3156000)
 75033 vmd  STRU  struct timespec { 0.003238000 }
 75033 vmd  STRU  struct kevent { ident=7, filter=EVFILT_READ, 
flags=0x1, fflags=0<>, data=15, udata=0x6cb750a7638 }
 75033 vmd  RET   kevent 1
 75033 vmd  CALL  clock_gettime(CLOCK_MONOTONIC,0x6cdf3156030)
 75033 vmd  STRU  struct timespec { 366729.439827252 }
 75033 vmd  RET   clock_gettime 0
 75033 vmd  CALL  kevent(0,0x6ce1a957800,0,0x6cd99f5c800,64,0x6cdf3156000)
 75033 vmd  STRU  struct timespec { 0.003227000 }
 75033 vmd  STRU  struct kevent { ident=7, filter=EVFILT_READ, 
flags=0x1, fflags=0<>, data=15, udata=0x6cb750a7638 }

vmctl start missing disk

[Ted Unangst]

start a vm with a missing disk

vmctl start banana -d whatever -i 1
vmctl: start vm command failed: No such file or directory

that's not much of a hint what went wrong.

Re: sparc64 -CURRENT in LDOM: ERROR: Last Trap: Fast Data Access Protection

[Ted Unangst]

Ax0n wrote:
> FWIW, the kernels running in my -stable guests are considerably larger than
> 8MB, and not much smaller than the -CURRENT kernels.

So it's actually the size of the code in the kernel, not the file size.

>From your boot message

Booting /virtual-devices@100/channel-devices@200/disk@0:a/bsd
8381472@0x100+7136@0x17fe420+196864@0x180+3997440@0x1830100

8381472 + 7136 (padding) = 8388608

Re: sparc64 -CURRENT in LDOM: ERROR: Last Trap: Fast Data Access Protection

[Ted Unangst]

Ax0n wrote:
> Is this limit specifically for LDOM guests? I have a Sun Blade 1500 I could
> compile a custom -CURRENT kernel with, if that might help. Though I'm not
> sure I want to do that with every snapshot I try.

Not specifically, but the limit can vary by hardware. If you want to run a
snapshot now, a custom kernel with a few devices removed will help. We'll have
to make a similar long term fix anyway.

Re: sparc64 -CURRENT in LDOM: ERROR: Last Trap: Fast Data Access Protection

[Ted Unangst]

Ax0n wrote:
> I have a SunFire T2000 that I've chopped up into LDOMs. The primary domain
> and six of the LDOMs are running 6.1-STABLE just fine. I pulled down the
> May 22 snapshot, and it installs (with a strange error, see bottom of
> post), but the LDOM crashes upon boot. I just tried again with the May 24th
> snapshot, and I'm getting the same error. This seems to dump me into
> OpenBoot, not ddb. I can provide a shell on the primary domain, and serial
> console (over ssh) access to a developer if needed. I am not subscribed to
> bugs@, so please copy me off-list.

There's a hardware/software limit that currently restricts the kernel to 8MB.
Larger than that and bad things happen. Hopefully someone will soon find a way
to reduce the size of the kernel.

Re: xterm fails ungracefully when saveLines resource value is too large

[Ted Unangst]

will.brokenbourgh2...@gmail.com wrote:
> >Synopsis:xterm fails ungracefully when saveLines resource value is too 
> >large
> >Category:system
> >Environment:
>   System  : OpenBSD 6.1
>   Details : OpenBSD 6.1 (GENERIC.MP) #6: Mon May 22 20:34:30 CEST 2017
>
> rob...@syspatch-61-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   When the xterm*saveLines resource value is too high (in this case 
> 99), xterm fails to run and issues the following error: 
> 
>   xterm: Error 91, errno 12: Cannot allocate memory
>   Reason: Alloc: calloc() failed on rows
> 
>   This error message is completely unhelpful from a user standpoint.  I 
> didn't know if this was system resource starvation or something else.  A 
> better way to handle this situation would be to set saveLines within xterm to 
> the maximum and print a warning that the saveLines variable is too large.

xterm is mainted outside openbsd. we're not likely to maintain a custom patch
for this.

Re: softraid i/o errors: which device causes them?

[Ted Unangst]

Paul de Weerd wrote:
> Hi all,
> 
> I've got a system with several softraid crypto devices mounted, and
> one seems to be having issues.  dmesg shows several of these:
> 
> softraid0: i/o error on block 1104 target 0 b_error 5
> 
> Is there a way to figure out which sd(4) device these come from?  Or
> what b_error 5 is?

error 5 is EIO, I/O error. Target 0 doesn't reveal much, though, that's not a
very helpful print out.

Re: softraid crypto performance regression

[Ted Unangst]

Mike Belopuhov wrote:
> On Wed, May 17, 2017 at 12:42 -0400, Ted Unangst wrote:
> > Stefan Sperling wrote:
> > > I also have some machines which are affected by this, and I am
> > > not sure what to about it. I cannot judge the advantages of
> > > either AES implementation.
> > 
> > There's very little advantage to a constant time implementation for disk
> > encryption. The threat model doesn't really include such side channels.
> >
> 
> This is simply not true if you have local users on the same box.
> http://www.cs.tau.ac.il/~tromer/papers/cache.pdf

I think we've reached agreement regarding reverting XTS, but for the benefit
of anyone following along at home or who might find this thread later...

The insider threat where I have some hostile user on my computer, who runs some
code to extract the disk key, then this user physically steals the computer to
recover data... I would say far fetched, but let's just go with minority
threat.

For most people, the threat is leaving a laptop bag in a taxi, or getting
burlged, or going through customs. Like 90%. 99% even? No insider threat here.

Another very popular use case doesn't even involve a threat. It's very easy to
repurpose a machine/disk that uses full disk encryption. Change the key, and
you've instantly wiped the disk. Personally, this is the main reason I use and
advocate everyone use disk encryption. It's not about machines being stolen,
but about machines I plan to give away in the future.

Re: softraid crypto performance regression

[Ted Unangst]

Stefan Sperling wrote:
> I also have some machines which are affected by this, and I am
> not sure what to about it. I cannot judge the advantages of
> either AES implementation.

There's very little advantage to a constant time implementation for disk
encryption. The threat model doesn't really include such side channels.

But I don't know how much burden it will be to maintain two implementations,
with the various defines like CRYPTO_AES_XTS and
CRYPTO_AES_XTS_FASTER_BUT_MAYBE_A_LITTLE_UNSAFE and deciding where to use
each.

Although, truth be told, XTS is only useful for disk encryption. It shouldn't
be used for network traffic. So we could just always make software XTS use
the original rijndael code. But this is mike's fun zone.

Re: Problem in installing: cannot recognize disk

[Ted Unangst]

Jonathan Gray wrote:
> sdmmc ends up attaching sd.
> 
> sdhc -> sdmmc -> scsibus -> sd
> 
> The submitter should try a release that isn't a year old and provide
> details of which particular stream model this is as the branding spans
> multiple generations of hardware with different variants.

There are many other problems, but openbsd didn't have any difficulty
detecting the sdmmc on the stream 7 and installing to it.

Re: segfault in grep

[Ted Unangst]

Michael Santos wrote:
> >Description:
> 
>   Use of uninitialized value in grep.
> 
> >How-To-Repeat:
> 
>   $ grep -o "" /etc/hosts
>   Segmentation fault (core dumped)
> 
> >Fix:

Thanks.

Re: 2017-03-24 amd64 snapshot upgrade : /etc/shells overwritten

[Ted Unangst]

Peter N. M. Hansteen wrote:
> Upgrading my laptop to the freshest snapshot about half an hour ago, I
> found that the line for my user's main shell, installed from a package
> and located under /usr/local/bin was no longer in /etc/shells.
> 
> The fix is to log in as root (or any other user with a base shell and
> some way to edit /etc/shells) and append the shell's line to /etc/shells.
> 
> Would it be possible to have upgrade's automatic sysmerge run merge
> /etc/shells?

Double check your procedure? shells is in the etc set. It should not be
overwritten by upgrades. In fact, sysmerge should handle it.

Re: doas -n fails even when no password would be requested

[Ted Unangst]

Otto Moerbeek wrote:
> On Tue, Feb 14, 2017 at 02:56:01PM -0500, Ted Unangst wrote:
> 
> > Paul de Weerd wrote:
> > > Well, in my case I can simply not use doas -n and ensure my script 
> > > works without prompting for passwords more than once (which is what I
> > > care about).  However, I have to say that doas works great in
> > > scripting setups: it asks for a password once and then all subsequent
> > > invocations of doas do not.  Once the script ends, the process group
> > > is gone and with it, the persist ticket.  So, yeah, persist works
> > > great for scripting.
> > 
> > I must admit this usage is kind of strange, but that doesn't mean bad.
> > Unexpected though. :)
> > 
> > However, do you need to use -n in this case? You've set things up so that 
> > the
> > first invocation asks for a password and then it relies on persist 
> > throughout.
> > So leave off of the -n?
> 
> H, isn't that a big race condition? What if the script takes
> longer than the persists time?

So that's the rationale for why it takes precendence. You can test the script
and get reliable results. Depends on whether one interprets -n to mean "don't
ask" or "don't wait".

As an alternative, let me mention the changes that were recently done to the
build system. Instead of using doas to elevate privileges during operations
like install, start as root and use doas to drop privileges to the build user.
This may require reworking the script somewhat, but I think it's a safer way
to do things.

Re: doas -n fails even when no password would be requested

[Ted Unangst]

Paul de Weerd wrote:
> Well, in my case I can simply not use doas -n and ensure my script 
> works without prompting for passwords more than once (which is what I
> care about).  However, I have to say that doas works great in
> scripting setups: it asks for a password once and then all subsequent
> invocations of doas do not.  Once the script ends, the process group
> is gone and with it, the persist ticket.  So, yeah, persist works
> great for scripting.

I must admit this usage is kind of strange, but that doesn't mean bad.
Unexpected though. :)

However, do you need to use -n in this case? You've set things up so that the
first invocation asks for a password and then it relies on persist throughout.
So leave off of the -n?

Maybe I will think about this some more. The current design, where -n
overrides persist, was deliberate. So it's not a "bug", but perhaps a wrong
decision. I just don't want anyone to rush to fix it.

Re: doas -n fails even when no password would be requested

[Ted Unangst]

Sebastian Benoit wrote:
> The -n option helps to use doas non-interactively.
> Its debateable wether 'persist' is useful with non-interactive usage, but
> this fixes it:

So the man page currently says "fail if doas would prompt for password."
although it would be more accurate to say "fail if does may prompt for a
password". The purpose of -n is to make sure a script will run with or without
persist, instead of being unpredictable.

Also, the way persist is tied to a process group means it's not great for
scripting anyway.

Re: doas -n fails even when no password would be requested

[Ted Unangst]

Theo Buehler wrote:
> On Tue, Feb 14, 2017 at 03:57:43PM +0100, Paul de Weerd wrote:
> > Consider the following:
> > 
> >1 [weerd@despair] $ doas true
> >2 doas (we...@despair.weirdnet.nl) password: 
> >3 [weerd@despair] $ doas true
> >4 [weerd@despair] $ doas -n true
> >5 doas: Authorization required
> > 
> > I have 'persist' to allow doas to not prompt for a password on
> > subsequent invocations.  However, then using 'doas -n' complains
> > "Authorization required" while the manpage says for -n: "Non
> > interactive mode, fail if doas would prompt for password."
> > 
> > Doas wouldn't prompt for a password if -n wasn't specified (see line
> > 3), so why does it fail in line 4?
> > 
> > Is this a bug in doas or in the manpage?
> > 
> 
> I think it's a bug in doas, even if the combination of -n and persist is
> a bit iffy. Here's a simple fix:

No, that's exactly why -n doesn't work with persist. Results should be
consistent.

-n means "no password". Adding persist allows to sometimes skip entering the
password, but the password is still "required".

Re: fd_getfile with 0xdeadbeef in rax

[Ted Unangst]

Martin Pieuchot wrote:
> Sure I can do that, I still want to add a comment since it might bite us
> later.
> 
> So a counter diff is like an ok?

sure. 

Re: fd_getfile with 0xdeadbeef in rax

[Ted Unangst]

Martin Pieuchot wrote:
> On 17/01/17(Tue) 00:24, Alexander Bluhm wrote:
> > On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
> > > kernel: protection fault trap, code=0
> > > Stopped at fd_getfile+0x20: testb $0x2,mptramp_gdt32_desc+0x1e(%r
> > > ax)
> > > ddb{3}> fd_getfile() at fd_getfile+0x20
> > > sys_fstat() at sys_fstat+0x43
> > > syscall() at syscall+0x27b
> > 
> > It crashes in fd_getfile() FILE_IS_USABLE(fp) as fdp->fd_ofiles has
> > been freed.
> 
> Are you sure?  The faulting instruction is:
> 
> /sys/kern/kern_descrip.c:190
>   80:   f6 40 40 02 testb  $0x2,0x40(%rax)
>   84:   75 e7   jne6d 
> 
> So %rax contains an incorrect value which is not NULL, are you
> suggesting that it is garbage due to free(9) poisoning the memory? 
> 
> If that's the case, the easiest fix in would be to do the allocations
> upfront.  An alternative solution discussed here at a2k17 would be to
> use a SRP to guarantee that fd_ofiles is not freed while another CPU is
> still referencing it.  That would also help for MP work.
> 
> Or could it be another race that your lock is preventing?
> 
> What about the diff below?  Cheeky does it help?

In that case, I think it's better to move the free down. This is more
idiomatic, free the old value and immediately replace.

Index: kern_descrip.c
===
RCS file: /cvs/src/sys/kern/kern_descrip.c,v
retrieving revision 1.136
diff -u -p -r1.136 kern_descrip.c
--- kern_descrip.c  24 Sep 2016 18:39:17 -  1.136
+++ kern_descrip.c  23 Jan 2017 22:02:07 -
@@ -849,9 +849,6 @@ fdexpand(struct proc *p)
memcpy(newofileflags, fdp->fd_ofileflags, copylen);
memset(newofileflags + copylen, 0, nfiles * sizeof(char) - copylen);
 
-   if (fdp->fd_nfiles > NDFILE)
-   free(fdp->fd_ofiles, M_FILEDESC, fdp->fd_nfiles * OFILESIZE);
-
if (NDHISLOTS(nfiles) > NDHISLOTS(fdp->fd_nfiles)) {
newhimap = mallocarray(NDHISLOTS(nfiles), sizeof(u_int),
M_FILEDESC, M_WAITOK);
@@ -877,6 +874,9 @@ fdexpand(struct proc *p)
fdp->fd_himap = newhimap;
fdp->fd_lomap = newlomap;
}
+
+   if (fdp->fd_nfiles > NDFILE)
+   free(fdp->fd_ofiles, M_FILEDESC, fdp->fd_nfiles * OFILESIZE);
fdp->fd_ofiles = newofile;
fdp->fd_ofileflags = newofileflags;
fdp->fd_nfiles = nfiles;

Re: fd_getfile with 0xdeadbeef in rax

[Ted Unangst]

Alexander Bluhm wrote:
> On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
> > kernel: protection fault trap, code=0
> > Stopped at fd_getfile+0x20: testb $0x2,mptramp_gdt32_desc+0x1e(%r
> > ax)
> > ddb{3}> fd_getfile() at fd_getfile+0x20
> > sys_fstat() at sys_fstat+0x43
> > syscall() at syscall+0x27b
> 
> It crashes in fd_getfile() FILE_IS_USABLE(fp) as fdp->fd_ofiles has
> been freed.
> 
> fdexpand() assumes that is has the write lock, calls free(fdp->fd_ofiles)
> and then sleeps in mallocarray(M_WAITOK) before updating fdp->fd_ofiles.
> 
> As fd_getfile() does not grab a readlock, it may get scheduled while
> fdexpand() sleeps.
> 
> Simply calling rw_enter_read(>fd_lock) in fd_getfile() does
> not work, as sometimes it is called with the writelock already held.
> Not sure wether such a write lock check is nice style, but it avoids
> to fix all callers.

I worry that this leaves some other race open. When I added fdplock(), I never
even considered a race in getfile. But fixing all the callers will be invasive
and it seems likely we'll miss one, so I guess this is the best approach.

noisy pkg_info errors

[Ted Unangst]

When a package doesn't exist, pkg_info prints error messages from the commands
it runs in the background.

pkg_info burritobox
Error from http://ftp.usa.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/
ftp: Error retrieving file: 404 Not Found
signify: gzheader truncated

Messages about truncated gzheaders are more confusing than informational.
Compare with the output of pkg_add for a package that doesn't exist:

pkg_add burritobox 
quirks-2.275 signed on 2016-12-20T16:07:48Z
Can't find burritobox

Re: Allow DDB to be disabled at boot time?

[Ted Unangst]

Adam McDougall wrote:
> 
> I just installed installed a snapshot build from:
> https://www.mirrorservice.org/pub/OpenBSD/snapshots/amd64/
> dated 2016-09-02 on a Dell R420 and I was able to reproduce
> the issue. I am willing to participate further if you or anyone
> else has ideas worth trying. Thanks.

you might have a look at src/sys/dev/ic/pckbd.c and some related files. you
can read the comments for various behaviors the driver tries to accomodate,
read the cvs log to learn about other stranger problems, etc. when all else
fills, stick delay() calls everywhere. and then of course there are other
operating systems which either work or not, each with their own driver and
comments and history that can be studied.

but the short answer to the simple question is that there is no way to disable
ddb at boot time.

Re: Stopped at bufq_destroy+0x83: movq 0(%rdx),%rax

[Ted Unangst]

FranciscoGaitán wrote:
> After making my SATA disk to work during some time, when I reboot or 
> halt I get this message (hand transcribed): 
> 
> syncing disks... done
> kernel: protection fault trap, code=0
> Stopped at bufq_destroy+0x83: movq 0(%rdx),%rax
> ddb{0}> trace
> bufq_destroy at bufq_destroy+0x83
> sddetach() at sddetach+0x3d
> config_detach() at config_detach+0x13c
> scsi_detach_lun() at scsi_detach_lun+0x97
> sr_discipline_shutdown() at src_discipline_shutdown+0x147
> sr_shutdown() at sr_shutdown+0x2a
> boot() at boot+0x144

I've seen this a few times, but not recently. I don't think it's fixed, but
it's not always so easy to trigger.

Re: bpfilter_create kassert panic

[Ted Unangst]

Alexander Bluhm wrote:
> Hi,
> 
> When running some scapy regression tests, a current i386 machine
> triggered this panic.

dunno if this is best. maybe. the refcounting of units implies that they can
last longer than close(). therefore, if open() is expecting close() to remove
the unit from the list, we must make sure close does that. dangling refs then
will be freed when the refcount drops.

The bpfilter_destory function is obfuscation at this point.

Alas, no time to test right now.

Index: bpf.c
===
RCS file: /cvs/src/sys/net/bpf.c,v
retrieving revision 1.142
diff -u -p -r1.142 bpf.c
--- bpf.c   10 Jun 2016 20:33:29 -  1.142
+++ bpf.c   24 Jul 2016 13:30:29 -
@@ -117,7 +117,6 @@ int bpf_sysctl_locked(int *, u_int, void
 
 struct bpf_d *bpfilter_lookup(int);
 struct bpf_d *bpfilter_create(int);
-void bpfilter_destroy(struct bpf_d *);
 
 /*
  * Reference count access to descriptor buffers
@@ -368,6 +367,7 @@ bpfclose(dev_t dev, int flag, int mode, 
if (d->bd_bif)
bpf_detachd(d);
bpf_wakeup(d);
+   LIST_REMOVE(d, bd_list);
D_PUT(d);
splx(s);
 
@@ -1494,7 +1494,7 @@ bpf_freed(struct bpf_d *d)
srp_update_locked(_insn_gc, >bd_rfilter, NULL);
srp_update_locked(_insn_gc, >bd_wfilter, NULL);
 
-   bpfilter_destroy(d);
+   free(d, M_DEVBUF, sizeof(*d));
 }
 
 /*
@@ -1651,12 +1651,6 @@ bpfilter_create(int unit)
return (bd);
 }
 
-void
-bpfilter_destroy(struct bpf_d *bd)
-{
-   LIST_REMOVE(bd, bd_list);
-   free(bd, M_DEVBUF, sizeof(*bd));
-}
 
 /*
  * Get a list of available data link type of the interface.

Re: The kernel did not panic

[Ted Unangst]

Atanas Vladimirov wrote:
> Snapshot was from Sat Jun 25 12:45:00 MDT 2016.

thanks, people are looking for causes.

Re: rm -rf "" # prints error

[Ted Unangst]

rkito...@gmail.com wrote:
> >Synopsis:rm -rf "" # prints error message but should be silent
> >Category:system
> >Environment:
>   System  : OpenBSD 5.9
>   Details : OpenBSD 5.9 (GENERIC.MP) #1888: Fri Feb 26 01:20:19 MST 
> 2016
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
>   The command:
> 
>   rm -rf ""
> 
>   prints to STDERR:
> 
>   rm: No such file or directory
> 
>   but it should print nothing because of the -f flag.

This fixes it.


Index: rm.c
===
RCS file: /cvs/src/bin/rm/rm.c,v
retrieving revision 1.37
diff -u -p -r1.37 rm.c
--- rm.c15 Apr 2016 23:09:57 -  1.37
+++ rm.c28 Jun 2016 14:49:42 -
@@ -150,8 +150,11 @@ rm_tree(char **argv)
flags = FTS_PHYSICAL;
if (!needstat)
flags |= FTS_NOSTAT;
-   if (!(fts = fts_open(argv, flags, NULL)))
-   err(1, NULL);
+   if (!(fts = fts_open(argv, flags, NULL))) {
+   if (!fflag || errno != ENOENT)
+   err(1, NULL);
+   return;
+   }
while ((p = fts_read(fts)) != NULL) {
switch (p->fts_info) {
case FTS_DNR:

Re: when to free tls config?

[Ted Unangst]

Joel Sing wrote:
> On Saturday 25 June 2016 22:58:59 Ted Unangst wrote:
> > It's unfortunately unclear from the documentation when it is safe to call
> > tls_config_free(). One might naively assume after a call to tls_configure,
> > but that's not correct as the config is also accessed during connect.
> 
> Right, we currently keep a reference to the tls_config struct within the 
> context. We could fix this by (a) improving the documentation (only free 
> after 
> all tls contexts have been freed), (b) copying the configuration struct when 
> tls_configure() is called or (c) reference counting on the tls_config. Out of 
> these it is probably preferable to do reference counting so that you can 
> immediately tls_config_free() after tls_configure(). Thoughts?

ref counting makes sense. It may be difficult for programs to correctly
maintain lifetimes for two dependent objects.

when to free tls config?

[Ted Unangst]

It's unfortunately unclear from the documentation when it is safe to call
tls_config_free(). One might naively assume after a call to tls_configure, but
that's not correct as the config is also accessed during connect.

Re: gzip pledge - change in behavior

[Ted Unangst]

Simon Mages wrote:
> I just noticed a problem with gzip in OpenBSD 5.9 introduced with pledge:
> if root compresses a file, the owner and group are not copied onto the created
> archive file:
> > user@obsd59:tmp >ls -l server.log
> > -rw-r--r--  1 user  wheel  345 Jun  3 09:16 server.log
> > user@obsd59:tmp >sudo gzip server.log
> > user@obsd59:tmp >ls -l server.log.gz
> > -rw-r--r--  1 root  wheel  234 Jun  3 09:16 server.log.gz
> 
> This change in behavior makes especially problems in newsyslog, as newsyslog
> sets owner and group of the rotated file prior to calling gzip.
> As a result, every .0 file which is compressed will belong to root:wheel 
> instead
> of the correct user and group.

ack. we're looking at it. pledge failing chown is intentional, but the
consequence in gzip was not.

Re: dig -p should abort instead of printing a warning

[Ted Unangst]

peter.van.d...@powerdns.com wrote:
> >Synopsis:dig -p prints a warning and ignores the argument
> >Category:user
> >Environment:
>   System  : OpenBSD 5.9
>   Details : OpenBSD 5.9 (GENERIC.MP) #4: Thu May 19 08:22:39 CEST 2016
>
> jas...@stable-59-amd64.mtier.org:/binpatchng/work-binpatch59-amd64/src/sys/arch/amd64/compile/GENERIC.MP
> 
>   Architecture: OpenBSD.amd64
>   Machine : amd64
> >Description:
> Since revision 1.15 at 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bind/bin/dig/dig.c, dig 
> ignores the -p option and instead sends to 53. I understand how support for 
> pledge() makes it impossible to support -p, however, just ignoring the 
> argument leads to several painful potential failure modes.
> 
> >How-To-Repeat:
> $ dig -p 5300 www.example.com @localhost
> ;; Warning, -p option ignored

This should work a little better.


Index: dig.c
===
RCS file: /cvs/src/usr.sbin/bind/bin/dig/dig.c,v
retrieving revision 1.16
diff -u -p -r1.16 dig.c
--- dig.c   11 Nov 2015 02:52:46 -  1.16
+++ dig.c   4 Jun 2016 18:28:08 -
@@ -1192,8 +1192,10 @@ dash_option(char *option, char *next, di
strlcpy(keyfile, value, sizeof(keyfile));
return (value_from_next);
case 'p':
-   fprintf(stderr, ";; Warning, -p option ignored\n");
-   /* port = (in_port_t) parse_uint(value, "port number", 
MAXPORT); */
+   if (parse_uint(value, "port number", MAXPORT) != 53) {
+   fprintf(stderr, ";; Error, only port 53 supported\n");
+   exit(1);
+   }
return (value_from_next);
case 'q':
if (!config_only) {

Re: Small lock.c patch

[Ted Unangst]

ilya.kali...@gmail.com wrote:
> Brace belongs to switch statement, not while loop
> 
> RCS file: /cvs/src/usr.bin/lock/lock.c,v
> retrieving revision 1.32
> diff -u -p -r1.32 lock.c
> --- lock.c  15 Oct 2015 02:35:04 -  1.32
> +++ lock.c  27 May 2016 21:41:15 -
> @@ -134,7 +134,7 @@ main(int argc, char *argv[])
> "usage: %s [-np] [-a style] [-t timeout]\n",
> __progname);
> exit(1);
> -   }
> +   }
> timeout.tv_sec = sectimeout * 60;
>  
> gethostname(hostname, sizeof(hostname));

I think these problems are best fixed by adding braces in both places. That's
a very large while() to leave a bare statement dangling off it.

Re: two audio beep bugs

[Ted Unangst]

Mark Kettenis wrote:
> 
> I personally think the wsconsctl settings should be respected by X.

> But perhaps we should have a more fundamental discussion about things
> first about how X should interact with wscons.  There is a more
> fundamental problem here where X assumes it has full control over the
> hardware.  There still is the volume key issue and there are problems

Implementation issues aside, as a user, my expectation is that X is a client
of the hardware. Therefore any "hardware" settings I have configured elsewhere
will be respected. I don't see any difference between speaker volume and
network interfaces. X uses my existing network configuration, so it should be
the same for other interfaces.

Re: a subset of kevent fails to work with setuid()

[Ted Unangst]

Luke Small wrote:
> The other kevent calls I use seem to work alright, but when run as root,
> this fails.

contrary to the manual, kevent() enforces additional restrictions on watching
procs. this is a local change that was made when kqueue was first imported,
but i can't think of a reason why.

Re: race between kqueue vnode note for writes triggering reads on a pre-mmapped file segment

[Ted Unangst]

Ben Woolley wrote:
> Do the updates of the mmap happen in the order that writes are made?
> If so, I could at least tell when coherence was reached.
> 
> But it isn't a huge deal. The main purpose was to be able to share
> memory between workers, and I can just do a read() into the shared
> memory to make the memory coherent.

I'm not sure it's possible to predict when a write() will become visible
via mmap(). If feasible, I would try doing the write via mmap as well.

Or as you say, if you only need shared memory, read() back into it would work.

Re: race between kqueue vnode note for writes triggering reads on a pre-mmapped file segment

[Ted Unangst]

Ben Woolley wrote:
> On both UFS and tmpfs, if you watch for updates to the file with
> kqueue, and pre-mmap a segment of the file, using the kqueue data to
> notify of updates to the file crusor, and append the file in a
> separate process, the written contents will populate AFTER the kqueue
> event is received, and is starting to be read. Part of the end of the
> read (of mapped memory) will still have 0s until the write completes.

openbsd does not have coherent mmap. you can't rely on read/write and mmap
working together.

Re: [bug?] pthread_barrier_wait

[Ted Unangst]

Kári Tristan Helgason wrote:
> I apologise in advance if the diff appears strange, I don't really know how 
> to get cvs to do what I want.

cvs diff -u helps a lot. :)

Re: [bug?] pthread_barrier_wait

[Ted Unangst]

Paul Irofti wrote:
> > What do you think?
> 
> I think this diff is even safer: it checks for threads entering and
> exiting the barrier while holding the mutex, and if both values are 0 it
> proceeds to destroy the barrier.
> 
> I also renamed sofar to in so that the relationship between threads is
> more obvious.

where did this go?

> 
> 
> Index: rthread.h
> ===
> RCS file: /cvs/src/lib/librthread/rthread.h,v
> retrieving revision 1.55
> diff -u -p -r1.55 rthread.h
> --- rthread.h 27 Jan 2016 08:40:05 -  1.55
> +++ rthread.h 16 Mar 2016 12:36:39 -
> @@ -141,7 +141,8 @@ struct pthread_barrier {
>   pthread_mutex_t mutex;
>   pthread_cond_t cond;
>   int threshold;
> - int sofar;
> + int in;
> + int out;
>   int generation;
>  };
>  
> Index: rthread_barrier.c
> ===
> RCS file: /cvs/src/lib/librthread/rthread_barrier.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 rthread_barrier.c
> --- rthread_barrier.c 23 Apr 2012 08:30:33 -  1.2
> +++ rthread_barrier.c 16 Mar 2016 12:36:39 -
> @@ -74,12 +74,18 @@ pthread_barrier_destroy(pthread_barrier_
>   if (barrier == NULL || *barrier == NULL)
>   return (EINVAL);
>  
> + if (pthread_mutex_trylock(&(*barrier)->mutex))
> + return (EBUSY);
> +
>   b = *barrier;
>  
> - if (b->sofar > 0)
> + if (b->out > 0 || b->in > 0) {
> + pthread_mutex_unlock(>mutex);
>   return (EBUSY);
> + }
>  
>   *barrier = NULL;
> + pthread_mutex_unlock(>mutex);
>   pthread_mutex_destroy(>mutex);
>   pthread_cond_destroy(>cond);
>   free(b);
> @@ -103,9 +109,10 @@ pthread_barrier_wait(pthread_barrier_t *
>   if ((rc = pthread_mutex_lock(>mutex)))
>   goto cancel;
>  
> - _rthread_debug(6, "sofar: %d, threshold: %d\n", b->sofar, b->threshold);
> - if (++b->sofar == b->threshold) {
> - b->sofar = 0;
> + _rthread_debug(6, "in: %d, threshold: %d\n", b->in, b->threshold);
> + if (++b->in == b->threshold) {
> + b->out = b->in - 1; /* mark thread exit */
> + b->in = 0;
>   b->generation++;
>   if ((rc = pthread_cond_broadcast(>cond)))
>   goto err;
> @@ -118,6 +125,7 @@ pthread_barrier_wait(pthread_barrier_t *
>   if ((rc = pthread_cond_wait(>cond, >mutex)))
>   goto err;
>   } while (gen == b->generation);
> + b->out--;   /* mark thread exit */
>   }
>  
>  err:
> 

openssl command can't be exited

[Ted Unangst]

Accidentally ask for a password:

#  openssl genrsa -aes256 -out /etc/ssl/private/server.key 2048
Generating RSA private key, 2048 bit long modulus
.+++
...+++
e is 65537 (0x10001)
Enter pass phrase for /etc/ssl/private/server.key:
822626074580:error:28069065:lib(40):UI_set_result:result too
small:/home/tedu/src/lib/libcrypto/crypto/../../libssl/src/crypto/ui/ui_lib.c:834:You
must type in 4 to 1023 characters
Enter pass phrase for /etc/ssl/private/server.key:
Enter pass phrase for /etc/ssl/private/server.key:

And now you can't quit. ^C doesn't work. ^D doesn't work. pkill openssl in
another terminal doesn't work. Nothing works.

Re: equivalence classes do NOT work at all

[Ted Unangst]

George Delles wrote:
> # echo á | grep '[[=a=]]'# echo ô | grep '[[=o=]]'# 
> On Linux to compare:
> # echo á | grep '[[=a=]]'á# echo ô | grep '[[=o=]]'ô#
> «STANDARDSThe grep utility is compliant with the IEEE Std 1003.1-2008 
> (“POSIX.1”) specification».
> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/egrep.1?query=grep
> 
> IEEE Std 1003.1:
> «9.3.5 RE Bracket Expression...It consists of one or more expressions: 
> collating elements, collating symbols, equivalence classes...»
> http://pubs.opengroup.org/onlinepubs/009696899/basedefs/xbd_chap09.html

unicode support is incomplete.

"apropos Vt=short" finds nothing

[Ted Unangst]

My understanding is that "apropos Vt=short" should find the stdarg.3 man page.
"apropos Va=va_list" does find the page, so I think I have a working index.

Re: dhclient doesn't work in trunk failover

[Ted Unangst]

timo.my...@wickedbsd.net wrote:
>   This might be caused by my current setup. I haven't used the ethernet
>   with my Thinkpad in ages. Previously I had the wireless and wired
>   clients in same subnet. This time the wireless and wired clients use
>   different subnets. Might explain why it previously has worked.

Long story short, trunk is used to combine two interfaces that are connected
to the same network. Combining two interfaces connected to different networks
works less well.

Re: libc getaddrinfo() bug

[Ted Unangst]

Serguey Parkhomovsky wrote:
> On Wed, Dec 16, 2015 at 06:08:22PM -0500, Ted Unangst wrote:
> > 
> > well, nobody fixed it, so if it's working, it's not using getaddrinfo.
> > 
> 
> Hmmm... looks like getaddrinfo was using my nameserver to resolve the
> decimal IP? I get the same behavior in -current by passing the
> AI_NUMERICHOST flag in hints. The following patch should fix this issue:

We're not convinced we want to fix this. The RFC may be mistaken in
perpetuating this silliness.

Re: screen brightness resets

[Ted Unangst]

Mark Kettenis wrote:
> > From: "Ted Unangst" <t...@tedunangst.com>
> > Date: Wed, 09 Dec 2015 06:49:42 -0500
> > 
> > Thinkpad X1 2015 (broadwell). This is a recent regression, though I'm not 
> > sure
> > when it was introduced. I have lidsuspend=0. When I close the lid and open 
> > it
> > again, the screen comes back at 100% brightness. As in, far too bright.
> > 
> > Previously, the screen would always open back up at the same brightness 
> > level
> > I closed it at. kettenis mentioned that the keyboard brightness keys work
> > (they do) but that's a recent addition. For many months, they did not. I
> > wonder if the changes are correlated.
> 
> They probably are.  And probably the weird behaviour of the brightness
> keys is related as well.  See my rants about ACPI being fucked because
> we claim to support both Windows 7 and Windows 8.  My suggestion would
> be to comment out most of the Windows versions in the "aml_valid_osi"
> array and see how the behaviour changes if you only enable the
> "Windows 2012", "Windows 2009" or "Windows 2006" entry.

It took a while to get around to it, but I'm now running with the diff below
and things seem much more sensible. The brightness controls still work, but
things don't reset every time I add or remove power.


Index: acpi/dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.218
diff -u -p -r1.218 dsdt.c
--- acpi/dsdt.c 20 Aug 2015 20:50:10 -  1.218
+++ acpi/dsdt.c 9 Dec 2015 14:06:50 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: dsdt.c,v 1.218 2015/08/20 20:50:10 kettenis Exp $ */
+/* $OpenBSD: dsdt.c,v 1.217 2015/05/04 10:42:06 jmatthew Exp $ */
 /*
  * Copyright (c) 2005 Jordan Hargrave <jor...@openbsd.org>
  *
@@ -1476,18 +1476,7 @@ struct aml_defval {
  * We return True for Windows to fake out nasty bad AML
  */
 char *aml_valid_osi[] = {
-   "Windows 2000",
-   "Windows 2001",
-   "Windows 2001.1",
-   "Windows 2001 SP0",
-   "Windows 2001 SP1",
-   "Windows 2001 SP2",
-   "Windows 2001 SP3",
-   "Windows 2001 SP4",
-   "Windows 2006",
"Windows 2009",
-   "Windows 2012",
-   "Windows 2013",
NULL
 };
 

Re: httpd crashes when fetching a hidden file located on a CD

[Ted Unangst]

Ted Unangst wrote:
> Jonathan Gray wrote:
> > > 
> > > There's one thing to add though, it looks like it happens for any file on
> > > cd9660, not just dotfiles.
> > 
> > It is worth pointing out that httpd has had trouble serving files off
> > specific filesystems in the past due to kqueue issues.
> > 
> > cd9660_vops does not currently set .vop_kqfilter, does anything change
> > if you set EVENT_NOKQUEUE before running httpd?
> 
> this maybe adds kqueue to cd9660.

We've confirmed this diff fixes the problem. However, there seems to be a
larger problem that httpd/libevent cannot gracefully handle the condition
where kevent returns an error. We are doomed to see this problem repeat if
that is not addressed.

screen brightness resets

[Ted Unangst]

Thinkpad X1 2015 (broadwell). This is a recent regression, though I'm not sure
when it was introduced. I have lidsuspend=0. When I close the lid and open it
again, the screen comes back at 100% brightness. As in, far too bright.

Previously, the screen would always open back up at the same brightness level
I closed it at. kettenis mentioned that the keyboard brightness keys work
(they do) but that's a recent addition. For many months, they did not. I
wonder if the changes are correlated.

Re: screen brightness resets

[Ted Unangst]

Ted Unangst wrote:
> Thinkpad X1 2015 (broadwell). This is a recent regression, though I'm not sure
> when it was introduced. I have lidsuspend=0. When I close the lid and open it
> again, the screen comes back at 100% brightness. As in, far too bright.
> 
> Previously, the screen would always open back up at the same brightness level
> I closed it at. kettenis mentioned that the keyboard brightness keys work
> (they do) but that's a recent addition. For many months, they did not. I
> wonder if the changes are correlated.

Little more info. Sorry, it's not related to lid closing. It's related to
power status changing. (which tends to happen in correlation with lid
operations).

Every time I attach or remove the power plug the screen jumps to 100%
brightness. This would almost even make sense if it only happened when
plugging in, but in what world do I want the screen to jump from 20% to 100%
when I *remove* power?

Re: httpd crashes when fetching a hidden file located on a CD

[Ted Unangst]

Jonathan Gray wrote:
> > 
> > There's one thing to add though, it looks like it happens for any file on
> > cd9660, not just dotfiles.
> 
> It is worth pointing out that httpd has had trouble serving files off
> specific filesystems in the past due to kqueue issues.
> 
> cd9660_vops does not currently set .vop_kqfilter, does anything change
> if you set EVENT_NOKQUEUE before running httpd?

this maybe adds kqueue to cd9660.


Index: cd9660_vnops.c
===
RCS file: /cvs/src/sys/isofs/cd9660/cd9660_vnops.c,v
retrieving revision 1.72
diff -u -p -r1.72 cd9660_vnops.c
--- cd9660_vnops.c  17 Apr 2015 04:43:20 -  1.72
+++ cd9660_vnops.c  8 Dec 2015 15:24:38 -
@@ -65,6 +65,9 @@
 #include 
 #include 
 
+int cd9660_kqfilter(void *v);
+
+
 /*
  * Structure for reading directories
  */
@@ -841,6 +844,7 @@ struct vops cd9660_vops = {
.vop_write  = cd9660_write,
.vop_ioctl  = cd9660_ioctl,
.vop_poll   = cd9660_poll,
+   .vop_kqfilter   = cd9660_kqfilter,
.vop_revoke = cd9660_revoke,
.vop_fsync  = cd9660_fsync,
.vop_remove = cd9660_remove,
@@ -947,3 +951,103 @@ struct vops cd9660_fifovops = {
.vop_advlock= fifo_advlock,
 };
 #endif /* FIFO */
+
+void filt_cd9660detach(struct knote *kn);
+int filt_cd9660read(struct knote *kn, long hint);
+int filt_cd9660write(struct knote *kn, long hint);
+int filt_cd9660vnode(struct knote *kn, long hint);
+
+struct filterops cd9660read_filtops = 
+   { 1, NULL, filt_cd9660detach, filt_cd9660read };
+struct filterops cd9660write_filtops = 
+   { 1, NULL, filt_cd9660detach, filt_cd9660write };
+struct filterops cd9660vnode_filtops = 
+   { 1, NULL, filt_cd9660detach, filt_cd9660vnode };
+
+int
+cd9660_kqfilter(void *v)
+{
+   struct vop_kqfilter_args *ap = v;
+   struct vnode *vp = ap->a_vp;
+   struct knote *kn = ap->a_kn;
+
+   switch (kn->kn_filter) {
+   case EVFILT_READ:
+   kn->kn_fop = _filtops;
+   break;
+   case EVFILT_WRITE:
+   kn->kn_fop = _filtops;
+   break;
+   case EVFILT_VNODE:
+   kn->kn_fop = _filtops;
+   break;
+   default:
+   return (EINVAL);
+   }
+
+   kn->kn_hook = (caddr_t)vp;
+
+   SLIST_INSERT_HEAD(>v_selectinfo.si_note, kn, kn_selnext);
+
+   return (0);
+}
+
+void
+filt_cd9660detach(struct knote *kn)
+{
+   struct vnode *vp = (struct vnode *)kn->kn_hook;
+
+   SLIST_REMOVE(>v_selectinfo.si_note, kn, knote, kn_selnext);
+}
+
+int
+filt_cd9660read(struct knote *kn, long hint)
+{
+   struct vnode *vp = (struct vnode *)kn->kn_hook;
+   struct iso_node *node = VTOI(vp);
+
+   /*
+* filesystem is gone, so set the EOF flag and schedule 
+* the knote for deletion.
+*/
+   if (hint == NOTE_REVOKE) {
+   kn->kn_flags |= (EV_EOF | EV_ONESHOT);
+   return (1);
+   }
+
+   kn->kn_data = node->i_size - kn->kn_fp->f_offset;
+   if (kn->kn_data == 0 && kn->kn_sfflags & NOTE_EOF) {
+   kn->kn_fflags |= NOTE_EOF;
+   return (1);
+   }
+
+   return (kn->kn_data != 0);
+}
+
+int
+filt_cd9660write(struct knote *kn, long hint)
+{
+   /*
+* filesystem is gone, so set the EOF flag and schedule 
+* the knote for deletion.
+*/
+   if (hint == NOTE_REVOKE) {
+   kn->kn_flags |= (EV_EOF | EV_ONESHOT);
+   return (1);
+   }
+
+   kn->kn_data = 0;
+   return (1);
+}
+
+int
+filt_cd9660vnode(struct knote *kn, long hint)
+{
+   if (kn->kn_sfflags & hint)
+   kn->kn_fflags |= hint;
+   if (hint == NOTE_REVOKE) {
+   kn->kn_flags |= EV_EOF;
+   return (1);
+   }
+   return (kn->kn_fflags != 0);
+}

crash in bufq_destroy

[Ted Unangst]

On reboot of a current amd64 kernel. running softraid crypto.

(hand transcription)

syncing disks... done
kernel: protection fault trap, code=0
Stopped at bufq_destroy+0x83: mo
ddb{0}> tr
bufq_destroy() at bufq_destroy+0x83
sddetach()
config_detach()
scsi_detach_lun()
sr_discipline_shutdown()
sr_shutdown()
boot()
reboot()
sys_reboot()

Re: playing video makes system unresponsive, but keeps playing

[Ted Unangst]

Michael McConville wrote:
> This is very pronounced. Firefox immediately spiked to almost 300% CPU
> on my four-core CPU and become non-responsive. I'm on Landry's Firefox
> 43 beta.
> 
> I haven't had issues with .mkv videos in VLC, though. Which encodings
> are giving you trouble?
> 
> I don't have time for more debugging at the moment. My dmesg is
> substituted below.

Is this before or after the change to xenocara intel-driver to disable
acceleration? (3 days ago)

Re: kernel panic - sparc64 on Netra X1 - psycho0: uncorrectable DMA error AFAR

[Ted Unangst]

Steven Chamberlain wrote:
> Hi,
> 
> (I have a Netra X1 also affected by this bug).
> 
> Stuart Henderson wrote:
> > could it be this?
> > 
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: d...@cvs.openbsd.org 2014/09/03 18:36:00
> > 
> > Modified files:
> > sys/sys: pool.h
> > sys/kern   : subr_pool.c
> > 
> > Log message:
> > rework how pools with large pages (>PAGE_SIZE) are implemented.
> > 
> > this moves the size of the pool page (not arch page) out of the
> > pool allocator into struct pool. this lets us create only two pools
> > for the automatically determined large page allocations instead of
> > 256 of them.
> > 
> > while here support using slack space in large pages for the
> > pool_item_header by requiring km_alloc provide pool page aligned
> > memory.
> > 
> > lastly, instead of doing incorrect math to figure how how many arch
> > pages to use for large pool pages, just use powers of two.
> > 
> > ok mikeb@
> 
> This is a really, really long shot, but could the calculation here on
> (unsigned int) pgsize underflow and return true when it shouldn't??
> 
> +  * Decide whether to put the page header off page to avoid
> +  * wasting too large a part of the page. Off-page page headers
> +  * go into an RB tree, so we can match a returned item with
> +  * its header based on the page address.
> +  */
> + if (pgsize - (size * items) > sizeof(struct pool_item_header)) {
> + flags |= PR_PHINPAGE;
> + off = pgsize - sizeof(struct pool_item_header);

That's interesting. I agree that test could perhaps be improved by writing it
if (pgsize > size * items + sizeof(struct pool_item_header))

dhclient spams me with no buffer space

[Ted Unangst]

On my X1 carbon, I unplugged the ethernet cable and switched to wireless. I
had a forgotten dhclient running for some time.

ifconfig reports the following:

ifconfig em0
em0: flags=8843 mtu 1500
lladdr 54:ee:75:3c:17:cb
priority: 0
media: Ethernet autoselect (none)
status: no carrier

dhclient however spammed me with messages like the following:

Nov 11 13:07:53 carbolite dhclient[24723]: DHCPDISCOVER on em0 - interval 10
Nov 11 13:07:53 carbolite dhclient[24723]: send_packet: No buffer space
available
Nov 11 13:08:03 carbolite dhclient[24723]: DHCPDISCOVER on em0 - interval 1
Nov 11 13:08:03 carbolite dhclient[24723]: send_packet: No buffer space
available
Nov 11 13:08:04 carbolite dhclient[24723]: No acceptable DHCPOFFERS received.
Nov 11 13:08:04 carbolite dhclient[24723]: No working leases in persistent
database - sleeping.
Nov 11 13:13:04 carbolite dhclient[24723]: DHCPDISCOVER on em0 - interval 3
Nov 11 13:13:04 carbolite dhclient[24723]: send_packet: No buffer space
available
Nov 11 13:13:07 carbolite dhclient[24723]: DHCPDISCOVER on em0 - interval 4

My expectation is that dhclient should observe a status of no carrier and
cease attempts to continue blasting packets.