Re: CVS: cvs.openbsd.org: src
On Mon, Nov 25, 2024 at 11:12:44PM -0700, Theo Buehler wrote: > CVSROOT: /cvs > Module name: src > Changes by: t...@cvs.openbsd.org2024/11/25 23:12:44 > > Modified files: > share/mk : bsd.regress.mk > > Log message: > Pass -g to CFLAGS for regression testing > > It is annoying to have a regress test crash and then be faced with question > marks in the backtrace, and then have to recompile and pass -g via DEBUG or > similar. > > This may bite people with small obj/. Let's see if anyone shouts. > > ok anton claudio Just an observation: after a full regress run on amd64 my obj partition only grew with 31MB so this should be negligible for most setups.
Re: CVS: cvs.openbsd.org: src
Was a build not done? Stuart Henderson wrote: > CVSROOT: /cvs > Module name: src > Changes by: st...@cvs.openbsd.org 2024/11/14 06:47:38 > > Modified files: > sys/net: if_tun.c if_tun.h > > Log message: > revert tun(4) changes for now, breaks in kdump build (TUNSCAP/TIOCEXT clash) > tb@ agrees >
Re: CVS: cvs.openbsd.org: src
On 05/11/24(Tue) 10:02, Martin Pieuchot wrote: > CVSROOT: /cvs > Module name: src > Changes by: m...@cvs.openbsd.org2024/11/05 10:02:19 > > Modified files: > sys/uvm: uvm_pmemrange.c > > Log message: > Protect the page daemon memory reserve from allocations in interrupt contexts. > > ok kettenis@ And ok miod@
Re: CVS: cvs.openbsd.org: src
On Thu, Oct 31, 2024 at 11:10:40PM -0600, Theo Buehler wrote: > CVSROOT: /cvs > Module name: src > Changes by: t...@cvs.openbsd.org2024/10/31 23:10:40 > > Modified files: > lib/libcrypto/ec: ec_local.h > > Log message: > Garbage collect field_div() member. > > It was only used by EC2M. This was ok jsing
Re: CVS: cvs.openbsd.org: src
Damien Miller wrote in : |CVSROOT: /cvs |Module name: src |Changes by: d...@cvs.openbsd.org 2024/10/23 21:15:47 | |Modified files: | usr.bin/ssh: ssh-agent.1 ssh-agent.c | |Log message: |amake ssh-agent drop all keys when it receives SIGUSR1; |let's users zap keys without access to $SSH_AUTH_SOCK ya!!! Thank you. I am just listening to -- if you believe it or not -- a DJ set of Laurent Garnier, playbt laurent_garnier-trouw_op_zondag__2013-02-10.ogg and RIGHT NOW we have Vertigo "Relight my Fire", what he plays so often, where wonderful children drop from the lips of beautiful women (in the chorus at least). |ok deraadt@ --End of --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |And in Fall, feel "The Dropbear Bard"s ball(s). | |The banded bear |without a care, |Banged on himselffore'er and e'er | |Farewell, dear collar bear
Re: CVS: cvs.openbsd.org: src
ive got the backout, i'll commit it now. > On 21 Oct 2024, at 15:45, Theo de Raadt wrote: > > Anton, back it out right away. > >> From owner-source-changes+M181516=deraadt=cvs.openbsd@openbsd.org Sun >> Oct 20 23:43:01 2024 >> Delivered-To: dera...@cvs.openbsd.org >> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; >> bh=GMhdKwZ2pE >> NofvlurQX6BF2bUqjtBvklZlgQXTQ75kc=; h=list-unsubscribe:list-subscribe: >> list-post:list-owner:list-id:list-help:in-reply-to:references:subject: >> cc:to:from:date; d=openbsd.org; b=b+ra1d4gGP7sOjogrPsDnwGfAltH2nKTeuUK >> eTM47Y77ZypvKzuPfokG9yYGKiGVzehzTHYahglGOQNvCE2Hvn8l+81dPfeTUWrUh4MqAH >> /e8FMkAPAk1J2gVJ+2whVdFbnqn+s+p9nOUOugFCan9Znz2jRq60eDYg/VwVKvNkrewo9S >> Km4VqyAli/BtCksfgyWcceaKCLZmsISUdUUoS4XpD1vKlf9FkfbYjOyfPdm7X7w79PQxwP >> 8vluzuWz87d3i1V7CcXQ2hMo2izo1E7fJhyRvWxsdyKJBCEQwTzpHJNz8oMNI/5PmzkIqk >> Q9kBi2+2pY/COAYBLmJCsZx0wA== >> Date: Mon, 21 Oct 2024 07:42:54 +0200 >> From: Anton Lindqvist >> To: David Gwynne >> Cc: source-chan...@cvs.openbsd.org >> Subject: Re: CVS: cvs.openbsd.org: src >> Mail-Followup-To: David Gwynne , >> source-chan...@cvs.openbsd.org >> References: >> MIME-Version: 1.0 >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> In-Reply-To: >> List-Help: <mailto:majord...@openbsd.org?body=help> >> List-ID: >> List-Owner: <mailto:owner-source-chan...@openbsd.org> >> List-Post: <mailto:source-changes@openbsd.org> >> List-Subscribe: <mailto:majord...@openbsd.org?body=sub%20source-changes> >> List-Unsubscribe: <mailto:majord...@openbsd.org?body=unsub%20source-changes> >> X-Loop: source-changes@openbsd.org >> Precedence: list >> Sender: owner-source-chan...@openbsd.org >> >> On Sun, Oct 20, 2024 at 05:28:17AM -0600, David Gwynne wrote: >>> CVSROOT: /cvs >>> Module name: src >>> Changes by: d...@cvs.openbsd.org 2024/10/20 05:28:17 >>> >>> Modified files: >>> sys/uvm: uvm_map.c uvm_map.h >>> >>> Log message: >>> try to simplify the locking code around busy maps. >>> >>> vm_maps have a "feature" where they can mark that they're being >>> operated on by a specific proc, and then release the rwlock protecting >>> their state. to relock, you have to be the same proc that marked >>> it busy. >>> >>> this diff tries to simplify it a bit. it basically has threads check >>> the busy field up front and rechecks the busy field inside the >>> rwlock. if you can sleep, it will sleep up front for the busy field >>> to become clear, rather than sleep on either the busy field or the >>> rwlock. some code paths clear the busy field without holding the >>> rwlock, so it doesn't make sense to me to be waiting for the busy >>> field but sleeping somewhere else. >>> >>> ok claudio@ mpi@ >> >> This caused by amd64 regress machine to panic. It goes straight to >> reboot, no chance of capturing any output from ddb. >> >> Here's a reproducer which compiles some Go application: >> >> $ make -C $BSDSRC/regress/lib/libcrypto/c2sp >> >> My amd64 desktop machine also locks up while starting firefox. >> >>
Re: CVS: cvs.openbsd.org: src
Anton, back it out right away. >From owner-source-changes+M181516=deraadt=cvs.openbsd@openbsd.org Sun Oct >20 23:43:01 2024 >Delivered-To: dera...@cvs.openbsd.org >DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=GMhdKwZ2pE > NofvlurQX6BF2bUqjtBvklZlgQXTQ75kc=; h=list-unsubscribe:list-subscribe: > list-post:list-owner:list-id:list-help:in-reply-to:references:subject: > cc:to:from:date; d=openbsd.org; b=b+ra1d4gGP7sOjogrPsDnwGfAltH2nKTeuUK > eTM47Y77ZypvKzuPfokG9yYGKiGVzehzTHYahglGOQNvCE2Hvn8l+81dPfeTUWrUh4MqAH > /e8FMkAPAk1J2gVJ+2whVdFbnqn+s+p9nOUOugFCan9Znz2jRq60eDYg/VwVKvNkrewo9S > Km4VqyAli/BtCksfgyWcceaKCLZmsISUdUUoS4XpD1vKlf9FkfbYjOyfPdm7X7w79PQxwP > 8vluzuWz87d3i1V7CcXQ2hMo2izo1E7fJhyRvWxsdyKJBCEQwTzpHJNz8oMNI/5PmzkIqk > Q9kBi2+2pY/COAYBLmJCsZx0wA== >Date: Mon, 21 Oct 2024 07:42:54 +0200 >From: Anton Lindqvist >To: David Gwynne >Cc: source-chan...@cvs.openbsd.org >Subject: Re: CVS: cvs.openbsd.org: src >Mail-Followup-To: David Gwynne , > source-chan...@cvs.openbsd.org >References: >MIME-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >In-Reply-To: >List-Help: <mailto:majord...@openbsd.org?body=help> >List-ID: >List-Owner: <mailto:owner-source-chan...@openbsd.org> >List-Post: <mailto:source-changes@openbsd.org> >List-Subscribe: <mailto:majord...@openbsd.org?body=sub%20source-changes> >List-Unsubscribe: <mailto:majord...@openbsd.org?body=unsub%20source-changes> >X-Loop: source-changes@openbsd.org >Precedence: list >Sender: owner-source-chan...@openbsd.org > >On Sun, Oct 20, 2024 at 05:28:17AM -0600, David Gwynne wrote: >> CVSROOT: /cvs >> Module name: src >> Changes by: d...@cvs.openbsd.org2024/10/20 05:28:17 >> >> Modified files: >> sys/uvm: uvm_map.c uvm_map.h >> >> Log message: >> try to simplify the locking code around busy maps. >> >> vm_maps have a "feature" where they can mark that they're being >> operated on by a specific proc, and then release the rwlock protecting >> their state. to relock, you have to be the same proc that marked >> it busy. >> >> this diff tries to simplify it a bit. it basically has threads check >> the busy field up front and rechecks the busy field inside the >> rwlock. if you can sleep, it will sleep up front for the busy field >> to become clear, rather than sleep on either the busy field or the >> rwlock. some code paths clear the busy field without holding the >> rwlock, so it doesn't make sense to me to be waiting for the busy >> field but sleeping somewhere else. >> >> ok claudio@ mpi@ > >This caused by amd64 regress machine to panic. It goes straight to >reboot, no chance of capturing any output from ddb. > >Here's a reproducer which compiles some Go application: > > $ make -C $BSDSRC/regress/lib/libcrypto/c2sp > >My amd64 desktop machine also locks up while starting firefox. > >
Re: CVS: cvs.openbsd.org: src
On 2024-10-21 08:42, Anton Lindqvist wrote: On Sun, Oct 20, 2024 at 05:28:17AM -0600, David Gwynne wrote: CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2024/10/20 05:28:17 Modified files: sys/uvm: uvm_map.c uvm_map.h Log message: try to simplify the locking code around busy maps. vm_maps have a "feature" where they can mark that they're being operated on by a specific proc, and then release the rwlock protecting their state. to relock, you have to be the same proc that marked it busy. this diff tries to simplify it a bit. it basically has threads check the busy field up front and rechecks the busy field inside the rwlock. if you can sleep, it will sleep up front for the busy field to become clear, rather than sleep on either the busy field or the rwlock. some code paths clear the busy field without holding the rwlock, so it doesn't make sense to me to be waiting for the busy field but sleeping somewhere else. ok claudio@ mpi@ This caused by amd64 regress machine to panic. It goes straight to reboot, no chance of capturing any output from ddb. Here's a reproducer which compiles some Go application: $ make -C $BSDSRC/regress/lib/libcrypto/c2sp My amd64 desktop machine also locks up while starting firefox. Hello, Maybe I hit the same problem last night - https://marc.info/?l=openbsd-misc&m=172946384419884&w=2 Best wishes, Atanas
Re: CVS: cvs.openbsd.org: src
On Sun, Oct 20, 2024 at 05:28:17AM -0600, David Gwynne wrote: > CVSROOT: /cvs > Module name: src > Changes by: d...@cvs.openbsd.org2024/10/20 05:28:17 > > Modified files: > sys/uvm: uvm_map.c uvm_map.h > > Log message: > try to simplify the locking code around busy maps. > > vm_maps have a "feature" where they can mark that they're being > operated on by a specific proc, and then release the rwlock protecting > their state. to relock, you have to be the same proc that marked > it busy. > > this diff tries to simplify it a bit. it basically has threads check > the busy field up front and rechecks the busy field inside the > rwlock. if you can sleep, it will sleep up front for the busy field > to become clear, rather than sleep on either the busy field or the > rwlock. some code paths clear the busy field without holding the > rwlock, so it doesn't make sense to me to be waiting for the busy > field but sleeping somewhere else. > > ok claudio@ mpi@ This caused by amd64 regress machine to panic. It goes straight to reboot, no chance of capturing any output from ddb. Here's a reproducer which compiles some Go application: $ make -C $BSDSRC/regress/lib/libcrypto/c2sp My amd64 desktop machine also locks up while starting firefox.
Re: CVS: cvs.openbsd.org: src
On Fri, Oct 18, 2024 at 06:35:35AM +0200, Anton Lindqvist wrote: > On Thu, Oct 17, 2024 at 03:11:35AM -0600, Claudio Jeker wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: clau...@cvs.openbsd.org 2024/10/17 03:11:35 > > > > Modified files: > > sys/kern : kern_sig.c kern_synch.c > > sys/sys: signalvar.h > > sys/ufs/mfs: mfs_vfsops.c > > > > Log message: > > Shortcut cursig when called during sleep setup. > > > > Add deep flag as function argument which is used by the sleep API but > > nowhere else. Both calls to sleep_signal_check() should skip the ugly > > bits of cursig(). > > > > In cursig() if deep once it is clear a signal will be taken keep the > > signal on the thread siglist and return. sleep_signal_check() will then > > return EINTR or ERESTART based on the signal context. There is no reason > > to do more in this special case. Especially stop/cont and the ptrace trap > > must be skipped here. Once the call makes it to userret the signal will be > > picked up again and handled in a safe location. > > > > Stopping singals need some additional logic since we don't want to abort > > the sleep just to stop a process. Since our SIGSTOP handling requires > > a major rewrite this will be posponed until then. > > regress/lib/libc/sys/t_waitid.c hanged over here and I suspect this is > the culprit. > > run-t_waitid-6 > 6 Test that waitid(2) handled stopped/continued process loop > ./t_waitid -r 6 > > /home/src/regress/lib/libc/sys/t_waitid.c:231: 'pid > 0' evaluated to false The problem is that this test uses nanosleep and nanosleep replaces ERESTART with EINTR and so the call fails. Takes many tries for me to hit this since a SIGSTOP needs to race against the nanosleep() call from the child. working on a fix for this. Need to pull in some changes from a bigger diff. -- :wq Claudio
Re: CVS: cvs.openbsd.org: src
On Thu, Oct 17, 2024 at 03:11:35AM -0600, Claudio Jeker wrote: > CVSROOT: /cvs > Module name: src > Changes by: clau...@cvs.openbsd.org 2024/10/17 03:11:35 > > Modified files: > sys/kern : kern_sig.c kern_synch.c > sys/sys: signalvar.h > sys/ufs/mfs: mfs_vfsops.c > > Log message: > Shortcut cursig when called during sleep setup. > > Add deep flag as function argument which is used by the sleep API but > nowhere else. Both calls to sleep_signal_check() should skip the ugly > bits of cursig(). > > In cursig() if deep once it is clear a signal will be taken keep the > signal on the thread siglist and return. sleep_signal_check() will then > return EINTR or ERESTART based on the signal context. There is no reason > to do more in this special case. Especially stop/cont and the ptrace trap > must be skipped here. Once the call makes it to userret the signal will be > picked up again and handled in a safe location. > > Stopping singals need some additional logic since we don't want to abort > the sleep just to stop a process. Since our SIGSTOP handling requires > a major rewrite this will be posponed until then. regress/lib/libc/sys/t_waitid.c hanged over here and I suspect this is the culprit. run-t_waitid-6 6 Test that waitid(2) handled stopped/continued process loop ./t_waitid -r 6 /home/src/regress/lib/libc/sys/t_waitid.c:231: 'pid > 0' evaluated to false
Re: CVS: cvs.openbsd.org: src
On Wed, Oct 16, 2024 at 05:12:31AM -0600, David Gwynne wrote: > CVSROOT: /cvs > Module name: src > Changes by: d...@cvs.openbsd.org2024/10/16 05:12:31 > > Modified files: > sys/net: if_tun.c > > Log message: > cut tun_init() out, it does pointless work. > > tun_init turns interface/stack config into a set of flags that > tun(4) keeps in tun_softc sc_flags, but never uses. > > ok miod@ kn@ regress/sbin/ifconfig now fails. Is that expected? > sbin/ifconfig Exit: 1 Duration: 00:00:22 (+00:00:01) Log: 184-sbin-ifconfig.log run-ppp-ifaddr-destination doas -n /sbin/ifconfig tun99 destroy 2>/dev/null || true doas -n /sbin/ifconfig tun99 create doas -n ./ifaddr tun99 10.188.253.74 10.188.253.75 ifaddr: SIOCSIFDSTADDR: Inappropriate ioctl for device *** Error 1 in . (Makefile:295 'run-ppp-ifaddr-destination') FAILED run-ppp-ifaddr-change-destination doas -n /sbin/ifconfig tun99 destroy 2>/dev/null || true doas -n /sbin/ifconfig tun99 create doas -n ./ifaddr tun99 10.188.253.1 10.188.253.11 ifaddr: SIOCSIFDSTADDR: Inappropriate ioctl for device *** Error 1 in . (Makefile:324 'run-ppp-ifaddr-change-destination') FAILED
Re: CVS: cvs.openbsd.org: src
Vào Th 4, 16 thg 10, 2024 vào lúc 10:53 Robert Nagy đã viết: > > CVSROOT:/cvs > Module name:src > Changes by: rob...@cvs.openbsd.org 2024/10/12 01:36:53 > > Modified files: > etc/etc.alpha : login.conf > etc/etc.amd64 : login.conf > etc/etc.arm64 : login.conf > etc/etc.armv7 : login.conf > etc/etc.hppa : login.conf > etc/etc.i386 : login.conf > etc/etc.landisk: login.conf > etc/etc.loongson: login.conf > etc/etc.luna88k: login.conf > etc/etc.macppc : login.conf > etc/etc.octeon : login.conf > etc/etc.powerpc64: login.conf > etc/etc.riscv64: login.conf > etc/etc.sparc64: login.conf > > Log message: > introduce a new build class to be used by the build user > > this class will be required for the upcoming llvm update > that requires bumped datasize because of llvm-tblgen > > ok deraadt@ > outsider's suggestion: should the datasize-cur and datasize-max get back to 1024M or 768M since bumps are caused by clang and we now have a "build" class?
Re: CVS: cvs.openbsd.org: src
On Thu, Oct 10, 2024 at 04:21:05PM GMT, Lucas Gabriel Vuotto wrote: > CVSROOT: /cvs > Module name: src > Changes by: lu...@cvs.openbsd.org 2024/10/10 16:21:05 > > Modified files: > lib/libc/sys : sysctl.2 > > Log message: > sysctl.2: NET_RT_DUMP defaults to the current rtable This was ok claudio jmc
Re: CVS: cvs.openbsd.org: src
On Wed, Oct 09, 2024 at 10:38:16AM +0200, Mark Kettenis wrote: > > Date: Wed, 9 Oct 2024 07:54:41 +0200 > > From: Anton Lindqvist > > > > On Tue, Oct 08, 2024 at 01:42:31PM -0600, Mark Kettenis wrote: > > > CVSROOT: /cvs > > > Module name: src > > > Changes by: kette...@cvs.openbsd.org2024/10/08 13:42:31 > > > > > > Modified files: > > > sys/dev/usb: ehci.c usb_mem.c usb_mem.h usbdivar.h xhci.c > > > > > > Log message: > > > Relax DMA restrictions on ehci(4) and xhci(4) controllers that can do > > > 64-bit DMA. > > > > > > ok mpi@, mlarkin@ > > > > My amd64 regress machine is now stuck during boot of the ramdisk. > > Last printed message on console: > > > > ehci0: unrecoverable error, controller halted > > > > Including a dmesg from yesterday where things did work. > > What happens if you revert just the ehci.c bit of that commit? Unfortunately not enough. A full revert was required to resurrect the machine.
Re: CVS: cvs.openbsd.org: src
sorry, went to wrong persons. Was for anton only. > Den ons 9 okt. 2024 kl 07:55 skrev Anton Lindqvist : > > My amd64 regress machine is now stuck during boot of the ramdisk. -- May the most significant bit of your life be positive.
Re: CVS: cvs.openbsd.org: src
Den ons 9 okt. 2024 kl 07:55 skrev Anton Lindqvist : > My amd64 regress machine is now stuck during boot of the ramdisk. > Last printed message on console: Hur blev du så skicklig på att trigga alla nya fel som uppstår av misstag? Tycker alltid att du och dina maskiner blir drabbade när det är "intressanta" diffar i obsd. Har du någon förbannelse över dig som gör att dina maskiner åker på allt elände eller är det "skicklighet" på nåt vis? 8^D -- May the most significant bit of your life be positive.
Re: CVS: cvs.openbsd.org: src
On Tue, Oct 08, 2024 at 01:42:31PM -0600, Mark Kettenis wrote: > CVSROOT: /cvs > Module name: src > Changes by: kette...@cvs.openbsd.org2024/10/08 13:42:31 > > Modified files: > sys/dev/usb: ehci.c usb_mem.c usb_mem.h usbdivar.h xhci.c > > Log message: > Relax DMA restrictions on ehci(4) and xhci(4) controllers that can do > 64-bit DMA. > > ok mpi@, mlarkin@ My amd64 regress machine is now stuck during boot of the ramdisk. Last printed message on console: ehci0: unrecoverable error, controller halted Including a dmesg from yesterday where things did work. OpenBSD 7.6-current (GENERIC.MP) #146: Mon Oct 7 23:30:05 UTC 2024 an...@amd64.basename.se:/home/src2/sys/arch/amd64/compile/GENERIC.MP real mem = 4152758272 (3960MB) avail mem = 4003667968 (3818MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdcd3d000 (60 entries) bios0: vendor LENOVO version "GIET99WW (2.49 )" date 03/17/2020 bios0: LENOVO 20ALCTO1WW efi0 at bios0: UEFI 2.3.1 efi0: Lenovo rev 0x2490 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM ASF! BATB FPDT UEFI SSDT DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz, 798.16 MHz, 06-45-01, patch 0026 cpu0: cpuid 1 edx=bfebfbff ecx=77fafbbf cpu0: cpuid 6 eax=77 ecx=9 cpu0: cpuid 7.0 ebx=27ab edx=9c000600 cpu0: cpuid a vers=3, gp=4, gpwidth=48, ff=3, ffwidth=48 cpu0: cpuid d.1 eax=1 cpu0: cpuid 8001 edx=2c100800 ecx=21 cpu0: cpuid 8007 edx=100 cpu0: MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 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 1 (application processor) cpu1: Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz, 798.16 MHz, 06-45-01, patch 0026 cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz, 798.16 MHz, 06-45-01, patch 0026 cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz, 798.17 MHz, 06-45-01, patch 0026 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 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpibtn0 at acpi0: LID_(wakeup) acpibtn1 at acpi0: SLPB(wakeup) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 acpibat0 at acpi0: BAT0 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0: version 1.0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "INT340F" at acpi0 not configured "INT33A0" at acpi0 not configured acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1 acpitz0 at acpi0: critical temperature is 200 degC acpivideo0 at acpi0: VID_ acpivout0 at acpivideo0: LCD0 acpivideo1 at acpi0: VID_ cpu0: using VERW MDS workaround (except on vmm entry) cpu0: Enhanced SpeedStep 798 MHz: speeds: 1701, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 782 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x09 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x09 drm0 at inteldrm0 inteldrm0: msi, HASWELL, gen 7 azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x09: msi azalia0: No codecs found "Intel 8 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel I218-LM" rev 0x04: msi, address 28:d2:44:a1:82:94 azalia1 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x04: msi azalia1: codecs: Realtek ALC292 audio0 at azalia1 ppb0 at pci0 dev 28 function 0 "Intel 8 Series PCIE" rev 0xe4: msi pci1 at ppb0 bus 2 rtsx0 at pci1 dev 0 function 0 "Realtek RTS5227 Card Reader" rev 0x01: msi sdmmc0 at rtsx0: 4-bit, dma ppb1 at pci0 dev 28 function 1 "Intel 8 Series PCIE" rev 0xe4: msi p
Re: CVS: cvs.openbsd.org: src
Let me update the review and test result.
On Thu, 3 Oct 2024 23:22:10 -0600 (MDT)
YASUOKA Masahiko wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: yasu...@cvs.openbsd.org 2024/10/03 23:22:10
>
> Modified files:
> sys/dev/pci: if_ix.c if_ix.h
>
> Log message:
> Expose {T,R}X desc trail and add link_enabled field to prepare VF
> support. diff from naito.yuichiro at gmail.com
>
> ok jan jmatthew
test blumn
ok blumn
Thanks,
Re: CVS: cvs.openbsd.org: src
On 2024-10-08 01:20 +01, Stuart Henderson wrote: > On 2024/10/07 17:47, Stuart Henderson wrote: >> CVSROOT: /cvs >> Module name: src >> Changes by: st...@cvs.openbsd.org 2024/10/07 17:47:00 >> >> Modified files: >> usr.sbin/acme-client: netproc.c >> >> Log message: >> When acme-client is run with -v, show the account URI from the Location >> header sent by the server in response to the newAccount API call (used for >> every cert request). This is useful if you want to set a CAA DNS record >> restricting issuance to a specific user account, rather than just "all of >> $whichever_acme_CA". ok florian >> > > oops, I was confused, florian ok'd a diff for something else, not this one :/ > no worries, I had already reviewed it but wanted to test it first before giving an OK. -- In my defence, I have been left unsupervised.
Re: CVS: cvs.openbsd.org: src
On 2024/10/07 17:47, Stuart Henderson wrote: > CVSROOT: /cvs > Module name: src > Changes by: st...@cvs.openbsd.org 2024/10/07 17:47:00 > > Modified files: > usr.sbin/acme-client: netproc.c > > Log message: > When acme-client is run with -v, show the account URI from the Location > header sent by the server in response to the newAccount API call (used for > every cert request). This is useful if you want to set a CAA DNS record > restricting issuance to a specific user account, rather than just "all of > $whichever_acme_CA". ok florian > oops, I was confused, florian ok'd a diff for something else, not this one :/
Re: CVS: cvs.openbsd.org: src
Steffen Nurpmeso wrote in
<20240914210907.soAX5D4j@steffen%sdaoden.eu>:
|Ingo Schwarze wrote in
| <5469171d82cb4...@cvs.openbsd.org>:
||CVSROOT: /cvs
||Module name: src
||Changes by: schwa...@cvs.openbsd.org2024/09/14 14:15:24
||
||Modified files:
|| usr.bin/calendar/calendars: calendar.history
||
||Log message:
||Drop the "Giant panda discovered" entry because it looks like
||half-way between misleadingly eurocentric and urban legend.
||It was so obviously suspect that it had already been marked "(?!)"
||since at least 4.3BSD-Tahoe (June 1988).
||
||Brought up by ,
||additional research by ,
||see https://marc.info/?l=openbsd-bugs&m=172634202204747 for details.
|
|nah. It was 1925 and it refers to Yeti sights ("tall, naked
|figure tugging at rhododendron bushes") in Nepal.
|
| Tombazi did not believe in the yeti, thinking the figure he saw
| was a traveling hermit. In 1925, he wrote a book about his
| experiences called Account of a Photographic Expedition to the
| Southern Glaciers of Kangchenjunga in the Sikkim Himalaya
|
|https://en.wikipedia.org/wiki/N._A._Tombazi
|
|And please, people, this is all about Shangri-La, you know,
|nothing fart-dry or the like. Don't smoke Opium, don't go the
|spiral staircase etc etc. Go ask Reinhold Messner.
|
|What a mess.
Berkeley. This is Berkeley. Bbbyy.
A nice Sunday i wish.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: CVS: cvs.openbsd.org: src
Ingo Schwarze wrote in
<5469171d82cb4...@cvs.openbsd.org>:
|CVSROOT: /cvs
|Module name: src
|Changes by: schwa...@cvs.openbsd.org2024/09/14 14:15:24
|
|Modified files:
| usr.bin/calendar/calendars: calendar.history
|
|Log message:
|Drop the "Giant panda discovered" entry because it looks like
|half-way between misleadingly eurocentric and urban legend.
|It was so obviously suspect that it had already been marked "(?!)"
|since at least 4.3BSD-Tahoe (June 1988).
|
|Brought up by ,
|additional research by ,
|see https://marc.info/?l=openbsd-bugs&m=172634202204747 for details.
nah. It was 1925 and it refers to Yeti sights ("tall, naked
figure tugging at rhododendron bushes") in Nepal.
Tombazi did not believe in the yeti, thinking the figure he saw
was a traveling hermit. In 1925, he wrote a book about his
experiences called Account of a Photographic Expedition to the
Southern Glaciers of Kangchenjunga in the Sikkim Himalaya
https://en.wikipedia.org/wiki/N._A._Tombazi
And please, people, this is all about Shangri-La, you know,
nothing fart-dry or the like. Don't smoke Opium, don't go the
spiral staircase etc etc. Go ask Reinhold Messner.
What a mess.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: CVS: cvs.openbsd.org: src
On Tue, Sep 10, 2024 at 03:38:45AM -0600, Claudio Jeker wrote: > CVSROOT: /cvs > Module name: src > Changes by: clau...@cvs.openbsd.org 2024/09/10 03:38:45 > > Modified files: > usr.sbin/bgpd : rde.c rde_attr.c rde_sets.c > > Log message: > Be more careful with aspath that have 0 length (aka the empty AS_PATH). > > Again malloc(0) is not portable and calling memcpy with a NULL pointer > and a 0 length is not allowed by the C standard. > This includes a similar check in rde_sets.c which just skips set_add if the number of elements is 0 and on top of this the rde.c change ensures that the imsg size of IMSG_RECONF_AS_SET_ITEMS includes at least one object and is object sized. -- :wq Claudio
Re: CVS: cvs.openbsd.org: src
On Thu, Sep 05, 2024 at 12:25:31PM +0200, Claudio Jeker wrote:
> On Thu, Sep 05, 2024 at 09:00:09AM +0200, Anton Lindqvist wrote:
> > On Wed, Sep 04, 2024 at 11:00:08AM -0600, Bob Beck wrote:
> > > CVSROOT: /cvs
> > > Module name: src
> > > Changes by: b...@cvs.openbsd.org2024/09/04 11:00:08
> > >
> > > Modified files:
> > > sys/ufs/ufs: ufs_ihash.c
> > >
> > > Log message:
> > > Work around vnode reuse bug resulting in a panic: vop_generic_badop
> > >
> > > Joel hit this frequently on the go builder, and this was
> > > also found by szykiller
> > >
> > > https://syzkaller.appspot.com/bug?extid=58bdde9f7a1a407514a7
> > > https://syzkaller.appspot.com/bug?extid=5779bc64fc4fdd0a5140
> > >
> > > This is based on a workaround originally done by visa@ and mbuhl@
> > > but not committed or widely distributed.
> > >
> > > Realistically this should be fixed more like the previous attempt
> > > with vdoom, but my attempts to do this at the moment are colliding
> > > with finding all sources of similar races, now that kernel unlocking
> > > is exposing these previously existing bugs
> > >
> > > for now, let's put in this ugly workaround
> > >
> > > ok deraadt@
> >
> > This causes regress/sys/fileops/ext2 to hang, I haven't made further
> > progress to see if other filesystems are also affected. Looks like the
> > thread is stuck in the kernel inside this new loop.
>
> Not proud but this is a possible fix.
>
> --
> :wq Claudio
>
> diff --git sys/ufs/ufs/ufs_ihash.c sys/ufs/ufs/ufs_ihash.c
> index b0d6ca3a5dd..744a9320fa3 100644
> --- sys/ufs/ufs/ufs_ihash.c
> +++ sys/ufs/ufs/ufs_ihash.c
> @@ -42,6 +42,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -109,7 +110,11 @@ loop:
> * dealt with so this can't happen.
> */
> if (VTOI(vp) != ip ||
> - (DIP(ip, nlink) <= 0 &&
> + ((
> +#ifdef EXT2FS
> + IS_EXT2_VNODE(ip->i_vnode) ? ip->i_e2fs_nlink <= 0 :
> +#endif
> + DIP(ip, nlink) <= 0) &&
>(vp->v_mount->mnt_flag & MNT_RDONLY) == 0)) {
> /*
>* This should recycle the inode immediately,
>
Thanks, this does solve the regression. ok anton@ fwiw
Re: CVS: cvs.openbsd.org: src
On Thu, Sep 05, 2024 at 09:00:09AM +0200, Anton Lindqvist wrote:
> On Wed, Sep 04, 2024 at 11:00:08AM -0600, Bob Beck wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: b...@cvs.openbsd.org2024/09/04 11:00:08
> >
> > Modified files:
> > sys/ufs/ufs: ufs_ihash.c
> >
> > Log message:
> > Work around vnode reuse bug resulting in a panic: vop_generic_badop
> >
> > Joel hit this frequently on the go builder, and this was
> > also found by szykiller
> >
> > https://syzkaller.appspot.com/bug?extid=58bdde9f7a1a407514a7
> > https://syzkaller.appspot.com/bug?extid=5779bc64fc4fdd0a5140
> >
> > This is based on a workaround originally done by visa@ and mbuhl@
> > but not committed or widely distributed.
> >
> > Realistically this should be fixed more like the previous attempt
> > with vdoom, but my attempts to do this at the moment are colliding
> > with finding all sources of similar races, now that kernel unlocking
> > is exposing these previously existing bugs
> >
> > for now, let's put in this ugly workaround
> >
> > ok deraadt@
>
> This causes regress/sys/fileops/ext2 to hang, I haven't made further
> progress to see if other filesystems are also affected. Looks like the
> thread is stuck in the kernel inside this new loop.
Not proud but this is a possible fix.
--
:wq Claudio
diff --git sys/ufs/ufs/ufs_ihash.c sys/ufs/ufs/ufs_ihash.c
index b0d6ca3a5dd..744a9320fa3 100644
--- sys/ufs/ufs/ufs_ihash.c
+++ sys/ufs/ufs/ufs_ihash.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
@@ -109,7 +110,11 @@ loop:
* dealt with so this can't happen.
*/
if (VTOI(vp) != ip ||
- (DIP(ip, nlink) <= 0 &&
+ ((
+#ifdef EXT2FS
+ IS_EXT2_VNODE(ip->i_vnode) ? ip->i_e2fs_nlink <= 0 :
+#endif
+ DIP(ip, nlink) <= 0) &&
(vp->v_mount->mnt_flag & MNT_RDONLY) == 0)) {
/*
* This should recycle the inode immediately,
Re: CVS: cvs.openbsd.org: src
On Wed, Sep 04, 2024 at 11:00:08AM -0600, Bob Beck wrote: > CVSROOT: /cvs > Module name: src > Changes by: b...@cvs.openbsd.org2024/09/04 11:00:08 > > Modified files: > sys/ufs/ufs: ufs_ihash.c > > Log message: > Work around vnode reuse bug resulting in a panic: vop_generic_badop > > Joel hit this frequently on the go builder, and this was > also found by szykiller > > https://syzkaller.appspot.com/bug?extid=58bdde9f7a1a407514a7 > https://syzkaller.appspot.com/bug?extid=5779bc64fc4fdd0a5140 > > This is based on a workaround originally done by visa@ and mbuhl@ > but not committed or widely distributed. > > Realistically this should be fixed more like the previous attempt > with vdoom, but my attempts to do this at the moment are colliding > with finding all sources of similar races, now that kernel unlocking > is exposing these previously existing bugs > > for now, let's put in this ugly workaround > > ok deraadt@ This causes regress/sys/fileops/ext2 to hang, I haven't made further progress to see if other filesystems are also affected. Looks like the thread is stuck in the kernel inside this new loop.
Re: CVS: cvs.openbsd.org: src
On 2024/08/29 06:44:00 +0200, Anton Lindqvist wrote:
> On Wed, Aug 28, 2024 at 05:40:33AM -0600, Omar Polo wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: o...@cvs.openbsd.org2024/08/28 05:40:33
> >
> > Modified files:
> > lib/libpcap: scanner.l
> >
> > Log message:
> > libpcap: replace hand-rolled number parser with strtol
> >
> > can't use strtonum here since it needs to handle octal and hex
> > notations as well. Part of a larger diff that's ok beck@
>
> This broke slaacd, vxlan, wg and rip6cksum regress. I doubt it was ever
> tested.
>
> According to the manual, strtol() assigns endptr to '\0' when the
> complete string is valid.
ok op@, sorry for the breakage. this was a later change that i have not
tested, i felt confident enough. sigh.
> Index: scanner.l
> ===
> RCS file: /cvs/src/lib/libpcap/scanner.l,v
> diff -u -p -r1.31 scanner.l
> --- scanner.l 28 Aug 2024 11:40:33 - 1.31
> +++ scanner.l 29 Aug 2024 04:43:02 -
> @@ -344,7 +344,7 @@ stoi(char *s)
>
> errno = 0;
> lval = strtol(s, &ep, 0);
> - if (*s == '\0' || *ep == '\0')
> + if (*s == '\0' || *ep != '\0')
> bpf_error("invalid number %s", s);
> if ((errno == ERANGE && (lval == LONG_MAX || lval == LONG_MIN)) ||
> (lval > INT_MAX || lval < INT_MIN))
Re: CVS: cvs.openbsd.org: src
It is a mistake copying the idiomatic example from the bottom of the
man page.
I always copy it, and then fix the indentation. Then, I consider
adjusting the local variables to match the idiomatic example. Usually
it feels better to do that, rather than edit every variable occurance
in the strtol incantation ("Double, double toil and trouble; fire burn
and cauldron bubble.")
Anton Lindqvist wrote:
> On Wed, Aug 28, 2024 at 05:40:33AM -0600, Omar Polo wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: o...@cvs.openbsd.org2024/08/28 05:40:33
> >
> > Modified files:
> > lib/libpcap: scanner.l
> >
> > Log message:
> > libpcap: replace hand-rolled number parser with strtol
> >
> > can't use strtonum here since it needs to handle octal and hex
> > notations as well. Part of a larger diff that's ok beck@
>
> This broke slaacd, vxlan, wg and rip6cksum regress. I doubt it was ever
> tested.
>
> According to the manual, strtol() assigns endptr to '\0' when the
> complete string is valid.
>
> Index: scanner.l
> ===
> RCS file: /cvs/src/lib/libpcap/scanner.l,v
> diff -u -p -r1.31 scanner.l
> --- scanner.l 28 Aug 2024 11:40:33 - 1.31
> +++ scanner.l 29 Aug 2024 04:43:02 -
> @@ -344,7 +344,7 @@ stoi(char *s)
>
> errno = 0;
> lval = strtol(s, &ep, 0);
> - if (*s == '\0' || *ep == '\0')
> + if (*s == '\0' || *ep != '\0')
> bpf_error("invalid number %s", s);
> if ((errno == ERANGE && (lval == LONG_MAX || lval == LONG_MIN)) ||
> (lval > INT_MAX || lval < INT_MIN))
>
Re: CVS: cvs.openbsd.org: src
On Wed, Aug 28, 2024 at 05:40:33AM -0600, Omar Polo wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: o...@cvs.openbsd.org2024/08/28 05:40:33
>
> Modified files:
> lib/libpcap: scanner.l
>
> Log message:
> libpcap: replace hand-rolled number parser with strtol
>
> can't use strtonum here since it needs to handle octal and hex
> notations as well. Part of a larger diff that's ok beck@
This broke slaacd, vxlan, wg and rip6cksum regress. I doubt it was ever
tested.
According to the manual, strtol() assigns endptr to '\0' when the
complete string is valid.
Index: scanner.l
===
RCS file: /cvs/src/lib/libpcap/scanner.l,v
diff -u -p -r1.31 scanner.l
--- scanner.l 28 Aug 2024 11:40:33 - 1.31
+++ scanner.l 29 Aug 2024 04:43:02 -
@@ -344,7 +344,7 @@ stoi(char *s)
errno = 0;
lval = strtol(s, &ep, 0);
- if (*s == '\0' || *ep == '\0')
+ if (*s == '\0' || *ep != '\0')
bpf_error("invalid number %s", s);
if ((errno == ERANGE && (lval == LONG_MAX || lval == LONG_MIN)) ||
(lval > INT_MAX || lval < INT_MIN))
Re: CVS: cvs.openbsd.org: src
On 2024/08/24 02:35, Stuart Henderson wrote: > CVSROOT: /cvs > Module name: src > Changes by: st...@cvs.openbsd.org 2024/08/24 02:35:24 > > Modified files: > usr.sbin/dhcpd : sync.c > > Log message: > Change DHCP_SYNC_LEASE messages from log_info to log_debug, they result > in quite a lot of noise in a typical dhcpd sync setup. > > From Michał Markowski, ok florian > also ok claudio
Re: CVS: cvs.openbsd.org: src
On Fri, Aug 23, 2024 at 11:29:08AM -0600, Theo de Raadt wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: dera...@cvs.openbsd.org 2024/08/23 11:29:08
>
> Modified files:
> games/quiz : Makefile
> games/quiz/datfiles: index
> Added files:
> games/quiz/datfiles: ship
> Removed files:
> games/quiz/datfiles: greek
>
> Log message:
> The greek quiz is so obscure that it is ridiculous -- noone can play
> this. Replace it with a new quiz about galley (ship) parts. This
> commit changes the *LAST UNMODIFIED ORIGINAL FILE* (meaning revision
> 1.1.1.1) from the original import that created OpenBSD on Oct 18,
> 1995. With this commit, we have completed an amusing mission of
> replacing the final parts of the original OpenBSD.
>
> We have reached OpenBSD of Theseus.
>
> ideas & assistance from mglocker, naval terminology help from jmc
>
Nice :-)
But one little thing. Somebody looking at the quiz index will not
notice that this is about ships:
$ /usr/games/quiz | grep desc
description part
We could do:
$ /usr/games/quiz | grep desc
ship-description part
or
$ /usr/games/quiz | grep desc
ship part
Index: games/quiz/datfiles/index
===
RCS file: /cvs/src/games/quiz/datfiles/index,v
diff -u -p -u -p -r1.4 index
--- games/quiz/datfiles/index 23 Aug 2024 17:29:08 - 1.4
+++ games/quiz/datfiles/index 23 Aug 2024 18:53:00 -
@@ -11,7 +11,7 @@
/usr/share/games/quiz.db/elements:symbol:number:weight:element
/usr/share/games/quiz.db/europe:Europe{an}:cap{ital}
/usr/share/games/quiz.db/flowers:flower{s}:meaning
-/usr/share/games/quiz.db/ship:description:part
+/usr/share/games/quiz.db/ship:ship-description:part
/usr/share/games/quiz.db/inca:inca:succ{essor}
/usr/share/games/quiz.db/latin:latin:english
/usr/share/games/quiz.db/locomotive:locomotive:name
Index: games/quiz/datfiles/index
===
RCS file: /cvs/src/games/quiz/datfiles/index,v
diff -u -p -u -p -r1.4 index
--- games/quiz/datfiles/index 23 Aug 2024 17:29:08 - 1.4
+++ games/quiz/datfiles/index 23 Aug 2024 18:53:00 -
@@ -11,7 +11,7 @@
/usr/share/games/quiz.db/elements:symbol:number:weight:element
/usr/share/games/quiz.db/europe:Europe{an}:cap{ital}
/usr/share/games/quiz.db/flowers:flower{s}:meaning
-/usr/share/games/quiz.db/ship:description:part
+/usr/share/games/quiz.db/ship:ship:part
/usr/share/games/quiz.db/inca:inca:succ{essor}
/usr/share/games/quiz.db/latin:latin:english
/usr/share/games/quiz.db/locomotive:locomotive:name
Re: CVS: cvs.openbsd.org: src
On 2024-08-22 02:17 -06, Florian Obser wrote: > CVSROOT: /cvs > Module name: src > Changes by: flor...@cvs.openbsd.org 2024/08/22 02:17:54 > > Modified files: > usr.sbin/bgpctl: parser.c > usr.sbin/bgpd : parse.y > usr.sbin/eigrpd: parse.y > usr.sbin/ldpd : parse.y > > Log message: > inet_pton returns 0 and -1 for error. > > Adjust the error check that is now wrong after the inet_aton -> inet_pton > conversion. > > Noticed by & OK bluhm. > OK tb > and OK claudio btw. this didn't matter in practice, the only case where inet_pton returns -1 is if af is not AF_INET or AF_INET6. But it might be copied to places where it does matter. -- In my defence, I have been left unsupervised.
Re: CVS: cvs.openbsd.org: src
Sorry, I lost `ok yasuoka'. -- ASOU Masato 2024/08/01 10:44 ASOU Masato : > CVSROOT:/cvs > Module name:src > Changes by: a...@cvs.openbsd.org2024/07/31 19:43:08 > > Modified files: > gnu/llvm/lldb/source/Plugins/Process/OpenBSDKernel: > > ProcessOpenBSDKernel.cpp > > Log message: > Possible to read the core file of a process. > >
Re: CVS: cvs.openbsd.org: src
Oops, that was ok deraadt@ On Tue, Aug 20, 2024 at 4:41 PM Philip Guenther wrote: > > CVSROOT:/cvs > Module name:src > Changes by: guent...@cvs.openbsd.org2024/08/20 17:40:39 > > Modified files: > bin/csh: sem.c > > Log message: > Now that we have dup2(), csh can use it instead of close()+dup(). > Also, as used here, dup/dup2 will clear the close-on-exec flag, so > delete the superfluous fcntl(F_SETFD,0) calls >
Re: CVS: cvs.openbsd.org: src
You said suspend/resume Do you mean for DVACT_WAKEUP? That's run with sleep allowed. Some drivers fix their hardware without sleeps in DVACT_RESUME. Others, do this async with sleeps in DVACT_WAKEUP. If you can gaurantee that no io transactions happen async to you, then what you do now is fine. And I see the same structure in other net80211 drivers. Stefan Sperling wrote: > CVSROOT: /cvs > Module name: src > Changes by: s...@cvs.openbsd.org2024/08/17 02:12:46 > > Modified files: > sys/dev/ic : qwx.c > > Log message: > enable qwx(4) ext irqs earlier for suspend/resume > > Enable ext IRQs like the Linux driver does it, not later. I did this > differently due to problems in early development that have since > been fixed. > > Fixes an interrupt storm during resume which prevents things like > key installation from working, leaving the network link dead. >
Re: CVS: cvs.openbsd.org: src
On Fri, Aug 16, 2024 at 01:30:18PM +0200, Mark Kettenis wrote:
> > Date: Fri, 16 Aug 2024 21:08:08 +1000
> > From: Jonathan Gray
> >
> > On Fri, Aug 16, 2024 at 11:59:08AM +0200, Mark Kettenis wrote:
> > > > Date: Fri, 16 Aug 2024 15:21:17 +1000
> > > > From: Jonathan Gray
> > > >
> > > > On Thu, Aug 15, 2024 at 11:04:32PM -0600, Theo de Raadt wrote:
> > > > > I'm no sure we should call it "BROKEN SUSPEND".
> > > > > It suspends, in our way. It just has a bug in CRS for RESUME.
> > > > >
> > > > > So maybe BROKEN_CRS?
> > > >
> > > > NOCRS?
> > >
> > > I wonder if we should also skip saving the state in that case. The
> > > Linux code also has seem workarounds for that. In that case the name
> > > of the flag should probably be XHCI_NOCSS.
> >
> > we can also skip restore by not setting sc_saved_state
>
> Right. I think I'd prefer an if () block instead of goto though.
Index: sys/dev/usb/xhci.c
===
RCS file: /cvs/src/sys/dev/usb/xhci.c,v
diff -u -p -r1.133 xhci.c
--- sys/dev/usb/xhci.c 15 Aug 2024 17:17:05 - 1.133
+++ sys/dev/usb/xhci.c 16 Aug 2024 11:40:16 -
@@ -626,23 +626,24 @@ xhci_suspend(struct xhci_softc *sc)
* will prevent the SoC from reaching its lowest idle state.
* So save the state here.
*/
+ if ((sc->sc_flags & XHCI_NOCCS) == 0) {
+ XOWRITE4(sc, XHCI_USBCMD, XHCI_CMD_CSS); /* Save state */
+ hcr = XOREAD4(sc, XHCI_USBSTS);
+ for (i = 0; i < 100; i++) {
+ usb_delay_ms(&sc->sc_bus, 1);
+ hcr = XOREAD4(sc, XHCI_USBSTS) & XHCI_STS_SSS;
+ if (!hcr)
+ break;
+ }
- XOWRITE4(sc, XHCI_USBCMD, XHCI_CMD_CSS); /* Save state */
- hcr = XOREAD4(sc, XHCI_USBSTS);
- for (i = 0; i < 100; i++) {
- usb_delay_ms(&sc->sc_bus, 1);
- hcr = XOREAD4(sc, XHCI_USBSTS) & XHCI_STS_SSS;
- if (!hcr)
- break;
- }
+ if (hcr) {
+ printf("%s: save state timeout\n", DEVNAME(sc));
+ xhci_reset(sc);
+ return;
+ }
- if (hcr) {
- printf("%s: save state timeout\n", DEVNAME(sc));
- xhci_reset(sc);
- return;
+ sc->sc_saved_state = 1;
}
-
- sc->sc_saved_state = 1;
/* Disable interrupts. */
XRWRITE4(sc, XHCI_IMOD(0), 0);
Index: sys/dev/usb/xhcivar.h
===
RCS file: /cvs/src/sys/dev/usb/xhcivar.h,v
diff -u -p -r1.15 xhcivar.h
--- sys/dev/usb/xhcivar.h 15 Aug 2024 17:17:05 - 1.15
+++ sys/dev/usb/xhcivar.h 16 Aug 2024 10:52:11 -
@@ -121,6 +121,9 @@ struct xhci_softc {
char sc_vendor[16]; /* Vendor string for root hub */
int sc_id_vendor; /* Vendor ID for root hub */
+
+ int sc_flags;
+#define XHCI_NOCCS 0x01
};
intxhci_init(struct xhci_softc *);
Index: sys/dev/pci/xhci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/xhci_pci.c,v
diff -u -p -r1.13 xhci_pci.c
--- sys/dev/pci/xhci_pci.c 24 May 2024 06:02:58 - 1.13
+++ sys/dev/pci/xhci_pci.c 16 Aug 2024 10:53:39 -
@@ -150,6 +164,11 @@ xhci_pci_attach(struct device *parent, s
if (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_FRESCO_FL1000 ||
PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_FRESCO_FL1400)
pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
+ break;
+ case PCI_VENDOR_AMD:
+ if (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_17_1X_XHCI_1 ||
+ PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_17_1X_XHCI_2)
+ psc->sc.sc_flags |= XHCI_NOCCS;
break;
}
Re: CVS: cvs.openbsd.org: src
On Fri, Aug 16, 2024 at 11:59:08AM +0200, Mark Kettenis wrote:
> > Date: Fri, 16 Aug 2024 15:21:17 +1000
> > From: Jonathan Gray
> >
> > On Thu, Aug 15, 2024 at 11:04:32PM -0600, Theo de Raadt wrote:
> > > I'm no sure we should call it "BROKEN SUSPEND".
> > > It suspends, in our way. It just has a bug in CRS for RESUME.
> > >
> > > So maybe BROKEN_CRS?
> >
> > NOCRS?
>
> I wonder if we should also skip saving the state in that case. The
> Linux code also has seem workarounds for that. In that case the name
> of the flag should probably be XHCI_NOCSS.
we can also skip restore by not setting sc_saved_state
Index: sys/dev/usb/xhci.c
===
RCS file: /cvs/src/sys/dev/usb/xhci.c,v
diff -u -p -r1.133 xhci.c
--- sys/dev/usb/xhci.c 15 Aug 2024 17:17:05 - 1.133
+++ sys/dev/usb/xhci.c 16 Aug 2024 10:53:27 -
@@ -620,6 +620,8 @@ xhci_suspend(struct xhci_softc *sc)
return;
}
+ if (sc->sc_flags & XHCI_NOCCS)
+ goto noccs;
/*
* Some Intel controllers will not power down completely
* unless they have seen a save state command. This in turn
@@ -643,6 +645,7 @@ xhci_suspend(struct xhci_softc *sc)
}
sc->sc_saved_state = 1;
+noccs:
/* Disable interrupts. */
XRWRITE4(sc, XHCI_IMOD(0), 0);
Index: sys/dev/usb/xhcivar.h
===
RCS file: /cvs/src/sys/dev/usb/xhcivar.h,v
diff -u -p -r1.15 xhcivar.h
--- sys/dev/usb/xhcivar.h 15 Aug 2024 17:17:05 - 1.15
+++ sys/dev/usb/xhcivar.h 16 Aug 2024 10:52:11 -
@@ -121,6 +121,9 @@ struct xhci_softc {
char sc_vendor[16]; /* Vendor string for root hub */
int sc_id_vendor; /* Vendor ID for root hub */
+
+ int sc_flags;
+#define XHCI_NOCCS 0x01
};
intxhci_init(struct xhci_softc *);
Index: sys/dev/pci/xhci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/xhci_pci.c,v
diff -u -p -r1.13 xhci_pci.c
--- sys/dev/pci/xhci_pci.c 24 May 2024 06:02:58 - 1.13
+++ sys/dev/pci/xhci_pci.c 16 Aug 2024 10:53:39 -
@@ -150,6 +164,11 @@ xhci_pci_attach(struct device *parent, s
if (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_FRESCO_FL1000 ||
PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_FRESCO_FL1400)
pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
+ break;
+ case PCI_VENDOR_AMD:
+ if (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_17_1X_XHCI_1 ||
+ PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_17_1X_XHCI_2)
+ psc->sc.sc_flags |= XHCI_NOCCS;
break;
}
Re: CVS: cvs.openbsd.org: src
On Thu, Aug 15, 2024 at 11:04:32PM -0600, Theo de Raadt wrote:
> I'm no sure we should call it "BROKEN SUSPEND".
> It suspends, in our way. It just has a bug in CRS for RESUME.
>
> So maybe BROKEN_CRS?
NOCRS?
Index: sys/dev/usb/xhci.c
===
RCS file: /cvs/src/sys/dev/usb/xhci.c,v
diff -u -p -r1.133 xhci.c
--- sys/dev/usb/xhci.c 15 Aug 2024 17:17:05 - 1.133
+++ sys/dev/usb/xhci.c 16 Aug 2024 05:14:59 -
@@ -463,7 +463,7 @@ xhci_config(struct xhci_softc *sc)
* it here. Otherwise some Intel controllers don't function
* correctly after resume.
*/
- if (sc->sc_saved_state) {
+ if (sc->sc_saved_state && (sc->sc_flags & XHCI_NOCRS) == 0) {
XOWRITE4(sc, XHCI_USBCMD, XHCI_CMD_CRS); /* Restore state */
hcr = XOREAD4(sc, XHCI_USBSTS);
for (i = 0; i < 100; i++) {
Index: sys/dev/usb/xhcivar.h
===
RCS file: /cvs/src/sys/dev/usb/xhcivar.h,v
diff -u -p -r1.15 xhcivar.h
--- sys/dev/usb/xhcivar.h 15 Aug 2024 17:17:05 - 1.15
+++ sys/dev/usb/xhcivar.h 16 Aug 2024 05:15:43 -
@@ -121,6 +121,9 @@ struct xhci_softc {
char sc_vendor[16]; /* Vendor string for root hub */
int sc_id_vendor; /* Vendor ID for root hub */
+
+ int sc_flags;
+#define XHCI_NOCRS 0x01
};
intxhci_init(struct xhci_softc *);
Index: sys/dev/pci/xhci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/xhci_pci.c,v
diff -u -p -r1.13 xhci_pci.c
--- sys/dev/pci/xhci_pci.c 24 May 2024 06:02:58 - 1.13
+++ sys/dev/pci/xhci_pci.c 16 Aug 2024 05:16:00 -
@@ -150,6 +164,11 @@ xhci_pci_attach(struct device *parent, s
if (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_FRESCO_FL1000 ||
PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_FRESCO_FL1400)
pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
+ break;
+ case PCI_VENDOR_AMD:
+ if (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_17_1X_XHCI_1 ||
+ PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_17_1X_XHCI_2)
+ psc->sc.sc_flags |= XHCI_NOCRS;
break;
}
Re: CVS: cvs.openbsd.org: src
I'm no sure we should call it "BROKEN SUSPEND". It suspends, in our way. It just has a bug in CRS for RESUME. So maybe BROKEN_CRS?
Re: CVS: cvs.openbsd.org: src
On Thu, Aug 15, 2024 at 10:03:12PM -0400, Bryan Steele wrote:
> On Thu, Aug 15, 2024 at 11:17:06AM -0600, Mark Kettenis wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: kette...@cvs.openbsd.org2024/08/15 11:17:06
> >
> > Modified files:
> > sys/dev/usb: xhci.c xhcivar.h
> >
> > Log message:
> > Upon resume, restore the saved state. Newer Intel xHCI controller (e.g.
> > those on Meteor Lake) need this, otherwise the ports are dead after
> > resume.
> >
> > ok mglocker@, deraadt@
>
> This seems to break USB (e.g: webcam) on resume for my old AMD laptop:
>
> xhci0 at pci2 dev 0 function 3 "AMD 17h/1xh xHCI" rev 0x00: msix, xHCI
> 1.10
> ...
> ugen0 detached
> uhub0 detached
> video0 detached
> uvideo0 detached
> uhub1 detached
> uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev
> 3.00/1.00 addr 1
> uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev
> 3.00/1.00 addr 1
> dwiic1: timed out waiting for stop intr
> uhub0: device problem, disabling port 2
> uhub1: device problem, disabling port 1
> wakeups: 0 1
> wakeup event: unknown
>
> Reverting this change fixes it.
an issue with that specific generation
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a7d57abcc8a5bdeb53bbf8e87558e8e0a2c2a29d
Index: sys/dev/usb/xhci.c
===
RCS file: /cvs/src/sys/dev/usb/xhci.c,v
diff -u -p -r1.133 xhci.c
--- sys/dev/usb/xhci.c 15 Aug 2024 17:17:05 - 1.133
+++ sys/dev/usb/xhci.c 16 Aug 2024 04:49:05 -
@@ -463,7 +463,7 @@ xhci_config(struct xhci_softc *sc)
* it here. Otherwise some Intel controllers don't function
* correctly after resume.
*/
- if (sc->sc_saved_state) {
+ if (sc->sc_saved_state && (sc->sc_flags & XHCI_BROKEN_SUSPEND) == 0) {
XOWRITE4(sc, XHCI_USBCMD, XHCI_CMD_CRS); /* Restore state */
hcr = XOREAD4(sc, XHCI_USBSTS);
for (i = 0; i < 100; i++) {
Index: sys/dev/usb/xhcivar.h
===
RCS file: /cvs/src/sys/dev/usb/xhcivar.h,v
diff -u -p -r1.15 xhcivar.h
--- sys/dev/usb/xhcivar.h 15 Aug 2024 17:17:05 - 1.15
+++ sys/dev/usb/xhcivar.h 16 Aug 2024 04:30:04 -
@@ -121,6 +121,9 @@ struct xhci_softc {
char sc_vendor[16]; /* Vendor string for root hub */
int sc_id_vendor; /* Vendor ID for root hub */
+
+ int sc_flags;
+#define XHCI_BROKEN_SUSPEND 0x01
};
intxhci_init(struct xhci_softc *);
Index: sys/dev/pci/xhci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/xhci_pci.c,v
diff -u -p -r1.13 xhci_pci.c
--- sys/dev/pci/xhci_pci.c 24 May 2024 06:02:58 - 1.13
+++ sys/dev/pci/xhci_pci.c 16 Aug 2024 04:54:52 -
@@ -150,6 +164,11 @@ xhci_pci_attach(struct device *parent, s
if (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_FRESCO_FL1000 ||
PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_FRESCO_FL1400)
pa->pa_flags &= ~PCI_FLAGS_MSI_ENABLED;
+ break;
+ case PCI_VENDOR_AMD:
+ if (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_17_1X_XHCI_1 ||
+ PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_AMD_17_1X_XHCI_2)
+ psc->sc.sc_flags |= XHCI_BROKEN_SUSPEND;
break;
}
Re: CVS: cvs.openbsd.org: src
On Thu, Aug 15, 2024 at 11:17:06AM -0600, Mark Kettenis wrote: > CVSROOT: /cvs > Module name: src > Changes by: kette...@cvs.openbsd.org2024/08/15 11:17:06 > > Modified files: > sys/dev/usb: xhci.c xhcivar.h > > Log message: > Upon resume, restore the saved state. Newer Intel xHCI controller (e.g. > those on Meteor Lake) need this, otherwise the ports are dead after > resume. > > ok mglocker@, deraadt@ This seems to break USB (e.g: webcam) on resume for my old AMD laptop: xhci0 at pci2 dev 0 function 3 "AMD 17h/1xh xHCI" rev 0x00: msix, xHCI 1.10 ... ugen0 detached uhub0 detached video0 detached uvideo0 detached uhub1 detached uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 dwiic1: timed out waiting for stop intr uhub0: device problem, disabling port 2 uhub1: device problem, disabling port 1 wakeups: 0 1 wakeup event: unknown Reverting this change fixes it. ugen0 detached uhub0 detached video0 detached uvideo0 detached uhub1 detached uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 ugen0 at uhub0 port 2 "Intel Bluetooth" rev 2.00/0.10 addr 2 dwiic1: timed out waiting for stop intr uvideo0 at uhub1 port 1 configuration 1 interface 0 "SunplusIT Inc hm1091_techfront" rev 2.00/0.13 addr 2 video0 at uvideo0 wakeups: 0 1 wakeup event: unknown
Re: CVS: cvs.openbsd.org: src
BTW, this is another occurance of the same failure condition: You did not build a full snapshot! This diff is old enough there was lots of time to build a snapshot with it. Vitaliy Makkoveev wrote: > Sorry about that. Please give me 5 min to fix it. > > > On 11 Aug 2024, at 23:46, Theo Buehler wrote: > > > > On Sun, Aug 11, 2024 at 09:10:53AM -0600, Vitaliy Makkoveev wrote: > >> CVSROOT: /cvs > >> Module name: src > >> Changes by:m...@cvs.openbsd.org2024/08/11 09:10:53 > >> > >> Modified files: > >>sys/kern : kern_exit.c kern_fork.c kern_sysctl.c > >>sys/sys: proc.h > >> > >> Log message: > >> Make exit1() wait sysctl(2) `allprocess' loops. > >> > >> Regardless on wired userland memory, KERN_FILE_BYPID and KERN_FILE_BYUID > >> `allprocess' loops have netlock provided sleep points, so concurrent > >> process exit(1) could crash kernel. > >> > >> The main exit1() problem is that process teardown begins while process > >> is still linked to `allprocess' list, and current code doesn't allow to > >> unlink it first. Wait for concurrent sysctl(2) `allprocess' loops > >> between PS_EXITING bit setting and list unlinking. Both KERN_FILE_BYPID > >> and KERN_FILE_BYUID loops do PS_EXITING check and won't deal with dying > >> process. Concurrent exit1() thread will wait loops keeping process > >> linked to `allprocess' list. > >> > >> Tested with i386 dpb(1) run. > >> Stress tests and ok bluhm. > >> > > > > libkvm fails to build with this diff because userland doesn't know about > > struct refcount: > > > > cc -O2 -pipe -g -D_LIBKVM -MD -MP -c /usr/src/lib/libkvm/kvm_proc.c -o > > kvm_proc.o > > In file included from /usr/src/lib/libkvm/kvm_proc.c:76: > > /usr/include/sys/proc.h:145:16: error: field has incomplete type 'struct > > refcnt' > >struct refcnt ps_refcnt; > > ^ >
Re: CVS: cvs.openbsd.org: src
On Sun, Aug 11, 2024 at 11:57:57PM +0300, Vitaliy Makkoveev wrote: > On Sun, Aug 11, 2024 at 11:51:47PM +0300, Vitaliy Makkoveev wrote: > > Sorry about that. Please give me 5 min to fix it. > > > > > On 11 Aug 2024, at 23:46, Theo Buehler wrote: > > > > > > libkvm fails to build with this diff because userland doesn't know about > > > struct refcount: > > > > > > cc -O2 -pipe -g -D_LIBKVM -MD -MP -c /usr/src/lib/libkvm/kvm_proc.c -o > > > kvm_proc.o > > > In file included from /usr/src/lib/libkvm/kvm_proc.c:76: > > > /usr/include/sys/proc.h:145:16: error: field has incomplete type 'struct > > > refcnt' > > >struct refcnt ps_refcnt; > > > ^ > > > > Add missing refcnt.h header. ok, thanks > > Index: sys/sys/proc.h > === > RCS file: /cvs/src/sys/sys/proc.h,v > retrieving revision 1.368 > diff -u -p -r1.368 proc.h > --- sys/sys/proc.h11 Aug 2024 15:10:53 - 1.368 > +++ sys/sys/proc.h11 Aug 2024 20:55:00 - > @@ -50,6 +50,7 @@ > #include /* For struct rusage */ > #include /* For struct rwlock */ > #include/* For struct sigio */ > +#include /* For struct refcnt */ > > #ifdef _KERNEL > #include
Re: CVS: cvs.openbsd.org: src
On Sun, Aug 11, 2024 at 11:51:47PM +0300, Vitaliy Makkoveev wrote: > Sorry about that. Please give me 5 min to fix it. > > > On 11 Aug 2024, at 23:46, Theo Buehler wrote: > > > > libkvm fails to build with this diff because userland doesn't know about > > struct refcount: > > > > cc -O2 -pipe -g -D_LIBKVM -MD -MP -c /usr/src/lib/libkvm/kvm_proc.c -o > > kvm_proc.o > > In file included from /usr/src/lib/libkvm/kvm_proc.c:76: > > /usr/include/sys/proc.h:145:16: error: field has incomplete type 'struct > > refcnt' > >struct refcnt ps_refcnt; > > ^ > Add missing refcnt.h header. Index: sys/sys/proc.h === RCS file: /cvs/src/sys/sys/proc.h,v retrieving revision 1.368 diff -u -p -r1.368 proc.h --- sys/sys/proc.h 11 Aug 2024 15:10:53 - 1.368 +++ sys/sys/proc.h 11 Aug 2024 20:55:00 - @@ -50,6 +50,7 @@ #include /* For struct rusage */ #include /* For struct rwlock */ #include /* For struct sigio */ +#include /* For struct refcnt */ #ifdef _KERNEL #include
Re: CVS: cvs.openbsd.org: src
Sorry about that. Please give me 5 min to fix it. > On 11 Aug 2024, at 23:46, Theo Buehler wrote: > > On Sun, Aug 11, 2024 at 09:10:53AM -0600, Vitaliy Makkoveev wrote: >> CVSROOT: /cvs >> Module name: src >> Changes by: m...@cvs.openbsd.org2024/08/11 09:10:53 >> >> Modified files: >> sys/kern : kern_exit.c kern_fork.c kern_sysctl.c >> sys/sys: proc.h >> >> Log message: >> Make exit1() wait sysctl(2) `allprocess' loops. >> >> Regardless on wired userland memory, KERN_FILE_BYPID and KERN_FILE_BYUID >> `allprocess' loops have netlock provided sleep points, so concurrent >> process exit(1) could crash kernel. >> >> The main exit1() problem is that process teardown begins while process >> is still linked to `allprocess' list, and current code doesn't allow to >> unlink it first. Wait for concurrent sysctl(2) `allprocess' loops >> between PS_EXITING bit setting and list unlinking. Both KERN_FILE_BYPID >> and KERN_FILE_BYUID loops do PS_EXITING check and won't deal with dying >> process. Concurrent exit1() thread will wait loops keeping process >> linked to `allprocess' list. >> >> Tested with i386 dpb(1) run. >> Stress tests and ok bluhm. >> > > libkvm fails to build with this diff because userland doesn't know about > struct refcount: > > cc -O2 -pipe -g -D_LIBKVM -MD -MP -c /usr/src/lib/libkvm/kvm_proc.c -o > kvm_proc.o > In file included from /usr/src/lib/libkvm/kvm_proc.c:76: > /usr/include/sys/proc.h:145:16: error: field has incomplete type 'struct > refcnt' >struct refcnt ps_refcnt; > ^
Re: CVS: cvs.openbsd.org: src
On Sun, Aug 11, 2024 at 09:10:53AM -0600, Vitaliy Makkoveev wrote: > CVSROOT: /cvs > Module name: src > Changes by: m...@cvs.openbsd.org2024/08/11 09:10:53 > > Modified files: > sys/kern : kern_exit.c kern_fork.c kern_sysctl.c > sys/sys: proc.h > > Log message: > Make exit1() wait sysctl(2) `allprocess' loops. > > Regardless on wired userland memory, KERN_FILE_BYPID and KERN_FILE_BYUID > `allprocess' loops have netlock provided sleep points, so concurrent > process exit(1) could crash kernel. > > The main exit1() problem is that process teardown begins while process > is still linked to `allprocess' list, and current code doesn't allow to > unlink it first. Wait for concurrent sysctl(2) `allprocess' loops > between PS_EXITING bit setting and list unlinking. Both KERN_FILE_BYPID > and KERN_FILE_BYUID loops do PS_EXITING check and won't deal with dying > process. Concurrent exit1() thread will wait loops keeping process > linked to `allprocess' list. > > Tested with i386 dpb(1) run. > Stress tests and ok bluhm. > libkvm fails to build with this diff because userland doesn't know about struct refcount: cc -O2 -pipe -g -D_LIBKVM -MD -MP -c /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o In file included from /usr/src/lib/libkvm/kvm_proc.c:76: /usr/include/sys/proc.h:145:16: error: field has incomplete type 'struct refcnt' struct refcnt ps_refcnt; ^
Re: CVS: cvs.openbsd.org: src
On Thu, Jul 18, 2024 at 10:26:23PM -0600, Christopher Zimmermann wrote: > CVSROOT: /cvs > Module name: src > Changes by: chr...@cvs.openbsd.org 2024/07/18 22:26:23 > > Modified files: > usr.sbin/relayd: relay_http.c > > Log message: > Keep Content-length header in HEAD responses. > > ok millert@ This commit introduced a regression as highlighted by the relayd regress tests. Some HEAD requests are now rejected as malformed, preserving the lost break fixes the issue. Index: relay_http.c === RCS file: /cvs/src/usr.sbin/relayd/relay_http.c,v diff -u -p -r1.89 relay_http.c --- relay_http.c19 Jul 2024 04:26:23 - 1.89 +++ relay_http.c20 Jul 2024 04:36:59 - @@ -435,6 +435,10 @@ relay_read_http(struct bufferevent *bev, kv_delete(&desc->http_headers, desc->http_lastheader); break; + case HTTP_METHOD_RESPONSE: + if (request_method == HTTP_METHOD_HEAD) + break; + /* FALLTHROUGH */ default: /* * Need to read data from the client
Re: CVS: cvs.openbsd.org: src
Todd C. Miller wrote: > CVSROOT: /cvs > Module name: src > Changes by: mill...@cvs.openbsd.org 2024/07/18 09:38:57 > > Modified files: > lib/libc/sys : link.2 > > Log message: > The source of a link (name1) may not be a directory. > > POSIX says this is implementation-dependent; OpenBSD does not allow > it. OK guenther@ > it's so dumb. Where is the code in cp(1) to handle the filesystem being a graph? Why is that code also missing in find(1)? Is that code in rsync? It's nowhere. Programs expect the filesystem to be a tree, not a graph.
Re: CVS: cvs.openbsd.org: src
On Sun, Jul 14, 2024 at 01:33:59PM -0600, Miod Vallat wrote: > CVSROOT: /cvs > Module name: src > Changes by: m...@cvs.openbsd.org2024/07/14 13:33:59 > > Added files: > sys/arch/armv7/include: elf.h > sys/arch/landisk/include: elf.h > sys/arch/loongson/include: elf.h > sys/arch/luna88k/include: elf.h > sys/arch/macppc/include: elf.h > sys/arch/octeon/include: elf.h > > Log message: > Add missing for compound arches. > > The spice^Wkernel must flow^Wbuild. Ah, that makes more sense. Thanks! -- jca
Re: CVS: cvs.openbsd.org: src
On Sat, Jul 13, 2024 at 10:06:34AM -0600, Florian Obser wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: flor...@cvs.openbsd.org 2024/07/13 10:06:34
>
> Modified files:
> sbin/slaacd: engine.c
>
> Log message:
> Reduce if_indextoname(3) usage.
>
> Don't ask the kernel to translate an if_index to a name if we are not
> running with verbose logging, it's not free.
This broke the ramdisk since log_getverbose() is by now required.
Currently running with the following diff.
Index: distrib/special/slaacd/Makefile
===
RCS file: /cvs/src/distrib/special/slaacd/Makefile,v
diff -u -p -r1.4 Makefile
--- distrib/special/slaacd/Makefile 14 Aug 2023 08:56:21 - 1.4
+++ distrib/special/slaacd/Makefile 14 Jul 2024 05:51:33 -
@@ -3,7 +3,7 @@
PROG= slaacd
COPTS+=-DSMALL
.PATH: ${.CURDIR}/../../../sbin/slaacd
-SRCS= engine.c frontend.c slaacd.c
+SRCS= engine.c frontend.c log.c slaacd.c
YFLAGS=
LDADD+=-levent -lutil
Index: sbin/slaacd/log.c
===
RCS file: /cvs/src/sbin/slaacd/log.c,v
diff -u -p -r1.2 log.c
--- sbin/slaacd/log.c 20 Mar 2021 16:46:03 - 1.2
+++ sbin/slaacd/log.c 14 Jul 2024 05:51:33 -
@@ -197,4 +197,13 @@ fatalx(const char *emsg, ...)
va_end(ap);
exit(1);
}
+
+#else
+
+int
+log_getverbose(void)
+{
+ return 0;
+}
+
#endif /* SMALL */
Re: CVS: cvs.openbsd.org: src
On 2024/06/04 00:51:15 -0600, Omar Polo wrote: > CVSROOT: /cvs > Module name: src > Changes by: o...@cvs.openbsd.org2024/06/04 00:51:15 > > Modified files: > usr.bin/mg : dired.c > > Log message: > now that we have dired-up-directory, use it in dired-jump too > > it's handy to be able to do C-x C-j (dired-jump) repeatedly to > navigate upwards starting from a buffer, and follows GNU Emacs > behaviour too. This was ok florian@, sorry!
Re: CVS: cvs.openbsd.org: src
On Mon, May 27, 2024 at 03:12:32AM -0600, Jonathan Gray wrote: > CVSROOT: /cvs > Module name: src > Changes by: j...@cvs.openbsd.org2024/05/27 03:12:32 > > Modified files: > lib/libssl : ssl.h > lib/libcrypto : ossl_typ.h > > Log message: > remove unused typedefs with structs that were removed > > ENGINE, SSL and SSL_CTX remain even though the structs in the typedefs > don't exist as they are used as incomplete types. this is only the case for struct engine_st tb@ notes that struct ssl_st and struct ssl_ctx_st used in libcrypto/ossl_typ.h exist in libssl/ssl_local.h
Re: CVS: cvs.openbsd.org: src
Argh, sorry. I'm not sure how that got missed. - todd
Re: CVS: cvs.openbsd.org: src
On Sun, May 05, 2024 at 12:30:00PM +1000, Jonathan Gray wrote:
> On Sat, May 04, 2024 at 04:59:21PM -0600, Todd C. Miller wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: mill...@cvs.openbsd.org 2024/05/04 16:59:21
> >
> > Modified files:
> > usr.bin/awk: FIXES b.c lib.c main.c run.c tran.c
> >
> > Log message:
> > Update awk to the May 4, 2024 version.
> > Fixes a use-after-free bug with ARGV for "delete ARGV".
>
> ld: error: undefined symbol: ARGVtab
>
> misses part of your upstream commit
> https://github.com/onetrueawk/awk/commit/d11b2d1a36e92518cea81c717169e2c97e8450d9
ok tb
>
> Index: lib.c
> ===
> RCS file: /cvs/src/usr.bin/awk/lib.c,v
> diff -u -p -r1.56 lib.c
> --- lib.c 4 May 2024 22:59:21 - 1.56
> +++ lib.c 5 May 2024 02:24:14 -
> @@ -332,14 +332,16 @@ int readcsvrec(char **pbuf, int *pbufsiz
>
> char *getargv(int n) /* get ARGV[n] */
> {
> + Array *ap;
> Cell *x;
> char *s, temp[50];
> - extern Array *ARGVtab;
> + extern Cell *ARGVcell;
>
> + ap = (Array *)ARGVcell->sval;
> snprintf(temp, sizeof(temp), "%d", n);
> - if (lookup(temp, ARGVtab) == NULL)
> + if (lookup(temp, ap) == NULL)
> return NULL;
> - x = setsymtab(temp, "", 0.0, STR, ARGVtab);
> + x = setsymtab(temp, "", 0.0, STR, ap);
> s = getsval(x);
> DPRINTF("getargv(%d) returns |%s|\n", n, s);
> return s;
>
Re: CVS: cvs.openbsd.org: src
On Sat, May 04, 2024 at 04:59:21PM -0600, Todd C. Miller wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: mill...@cvs.openbsd.org 2024/05/04 16:59:21
>
> Modified files:
> usr.bin/awk: FIXES b.c lib.c main.c run.c tran.c
>
> Log message:
> Update awk to the May 4, 2024 version.
> Fixes a use-after-free bug with ARGV for "delete ARGV".
ld: error: undefined symbol: ARGVtab
misses part of your upstream commit
https://github.com/onetrueawk/awk/commit/d11b2d1a36e92518cea81c717169e2c97e8450d9
Index: lib.c
===
RCS file: /cvs/src/usr.bin/awk/lib.c,v
diff -u -p -r1.56 lib.c
--- lib.c 4 May 2024 22:59:21 - 1.56
+++ lib.c 5 May 2024 02:24:14 -
@@ -332,14 +332,16 @@ int readcsvrec(char **pbuf, int *pbufsiz
char *getargv(int n) /* get ARGV[n] */
{
+ Array *ap;
Cell *x;
char *s, temp[50];
- extern Array *ARGVtab;
+ extern Cell *ARGVcell;
+ ap = (Array *)ARGVcell->sval;
snprintf(temp, sizeof(temp), "%d", n);
- if (lookup(temp, ARGVtab) == NULL)
+ if (lookup(temp, ap) == NULL)
return NULL;
- x = setsymtab(temp, "", 0.0, STR, ARGVtab);
+ x = setsymtab(temp, "", 0.0, STR, ap);
s = getsval(x);
DPRINTF("getargv(%d) returns |%s|\n", n, s);
return s;
Re: CVS: cvs.openbsd.org: src
On Wed, Apr 17, 2024 at 08:55:38AM +0200, Anton Lindqvist wrote: > On Tue, Apr 16, 2024 at 08:37:49AM -0600, Florian Obser wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: flor...@cvs.openbsd.org 2024/04/16 08:37:49 > > > > Modified files: > > sys/netinet6 : in6.c > > > > Log message: > > Destination addresses make no sense on loopback interfaces. > > > > While here use (variable & FLAG) or !(variable & FLAG) consistently in > > in6_update_ifa(). > > > > Discussed with claudio > > OK denis > > This change introduced 15 regress failures, all related to inet6. > > https://regress.basename.se/ > > Excerpt from sys/net/mpath showing the symptom: > > doas -n /sbin/ifconfig lo19 inet6 fc00::19 alias > ifconfig: lo19: SIOCIFAFATTACH: Invalid argument > ifconfig: SIOCAIFADDR: Invalid argument Localhost ::1 and all inet6 adresses are missing at loopback. ==> /etc/hostname.lo0 <== inet alias 10.188.0.74 255.255.255.255 inet6 fdd7:e83e:66bc:0::74 128 before # ifconfig lo0 lo0: flags=2008049 mtu 32768 index 5 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet 127.0.0.1 netmask 0xff00 inet 10.188.0.74 netmask 0x inet6 fdd7:e83e:66bc::74 prefixlen 128 after # ifconfig lo0 lo0: flags=2008049 mtu 32768 index 5 priority 0 llprio 3 groups: lo inet 127.0.0.1 netmask 0xff00 inet 10.188.0.74 netmask 0x
Re: CVS: cvs.openbsd.org: src
reverted, sorry for the breakage, I did my tests on an old kernel :( On 2024-04-17 02:07 -06, Theo de Raadt wrote: > There's a long history of using loX interfaces for such things. > > What might make sense is to restrict it on lo0 ? > it's not about configuring additional IP addresses on loopback interfaces but on how they are configured. What ifconfig does internally is set a *destination* of ::1, i.e. as if called like this: /sbin/ifconfig lo19 inet6 fc00::19/128 ::1 I suspect that something somewhere in our stack depends on ::1 being there to deliver packets correctly. I'll leave this alone and punt it to future IPv6 hackers. I think we probably should enforce in the kernel that ifconfig sends us ::1 as the destination address and nothing else. >>On Tue, Apr 16, 2024 at 08:37:49AM -0600, Florian Obser wrote: >>> CVSROOT:/cvs >>> Module name:src >>> Changes by: flor...@cvs.openbsd.org 2024/04/16 08:37:49 >>> >>> Modified files: >>> sys/netinet6 : in6.c >>> >>> Log message: >>> Destination addresses make no sense on loopback interfaces. >>> >>> While here use (variable & FLAG) or !(variable & FLAG) consistently in >>> in6_update_ifa(). >>> >>> Discussed with claudio >>> OK denis >> >>This change introduced 15 regress failures, all related to inet6. >> >> https://regress.basename.se/ >> >>Excerpt from sys/net/mpath showing the symptom: >> >> doas -n /sbin/ifconfig lo19 inet6 fc00::19 alias >> ifconfig: lo19: SIOCIFAFATTACH: Invalid argument >> ifconfig: SIOCAIFADDR: Invalid argument >> >> > -- In my defence, I have been left unsupervised.
Re: CVS: cvs.openbsd.org: src
There's a long history of using loX interfaces for such things. What might make sense is to restrict it on lo0 ? >On Tue, Apr 16, 2024 at 08:37:49AM -0600, Florian Obser wrote: >> CVSROOT: /cvs >> Module name: src >> Changes by: flor...@cvs.openbsd.org 2024/04/16 08:37:49 >> >> Modified files: >> sys/netinet6 : in6.c >> >> Log message: >> Destination addresses make no sense on loopback interfaces. >> >> While here use (variable & FLAG) or !(variable & FLAG) consistently in >> in6_update_ifa(). >> >> Discussed with claudio >> OK denis > >This change introduced 15 regress failures, all related to inet6. > > https://regress.basename.se/ > >Excerpt from sys/net/mpath showing the symptom: > > doas -n /sbin/ifconfig lo19 inet6 fc00::19 alias > ifconfig: lo19: SIOCIFAFATTACH: Invalid argument > ifconfig: SIOCAIFADDR: Invalid argument > >
Re: CVS: cvs.openbsd.org: src
On Tue, Apr 16, 2024 at 08:37:49AM -0600, Florian Obser wrote: > CVSROOT: /cvs > Module name: src > Changes by: flor...@cvs.openbsd.org 2024/04/16 08:37:49 > > Modified files: > sys/netinet6 : in6.c > > Log message: > Destination addresses make no sense on loopback interfaces. > > While here use (variable & FLAG) or !(variable & FLAG) consistently in > in6_update_ifa(). > > Discussed with claudio > OK denis This change introduced 15 regress failures, all related to inet6. https://regress.basename.se/ Excerpt from sys/net/mpath showing the symptom: doas -n /sbin/ifconfig lo19 inet6 fc00::19 alias ifconfig: lo19: SIOCIFAFATTACH: Invalid argument ifconfig: SIOCAIFADDR: Invalid argument
Re: CVS: cvs.openbsd.org: src
Sebastien Marie writes: > CVSROOT: /cvs > Module name: src > Changes by: sema...@cvs.openbsd.org 2024/04/04 10:00:51 > > Modified files: > usr.bin/ssh/ssh-agent: Makefile > > Log message: > set right mode on ssh-agent at boot-time > > which sthen@ s/which/with/ > ok deraadt@ -- Sebastien Marie
Re: CVS: cvs.openbsd.org: src
On Mon, Apr 01, 2024 at 09:50:17AM -0600, Theo de Raadt wrote: > CVSROOT: /cvs > Module name: src > Changes by: dera...@cvs.openbsd.org 2024/04/01 09:50:17 > > Modified files: > usr.bin/ssh/ssh-agent: Makefile > > Log message: > also create a relink kit for ssh-agent, since it is a long-running setgid > program carrying keys with some (not very powerful) communication channels. > solution for testing the binary from dtucker. agreement from djm. > Will add it into /etc/rc in a few days. The BINMODE change, removing read permissions from group and others, caused ssh regress to fail. Flooded with the following message: cat: /usr/bin/ssh-agent: Permission denied
Re: CVS: cvs.openbsd.org: src
Scott Soule Cheloha wrote in <3d329ff2b7df9...@cvs.openbsd.org>: ... |Log message: |gnu/usr.bin: import xz-utils 5.6.1 Dschihad(-75) in Ramadan! That is very unreligious. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: CVS: cvs.openbsd.org: src
On Thu, Mar 28, 2024 at 05:16:32AM -0600, Joel Sing wrote: > CVSROOT: /cvs > Module name: src > Changes by: js...@cvs.openbsd.org 2024/03/28 05:16:32 > > Modified files: > lib/libcrypto : x86_64cpuid.pl > > Log message: > Remove .init section that calls OPENSSL_cpuid_setup on amd64. > > OPENSSL_cpuid_setup() is already called from OPENSSL_crypto_init(), hence > we do not need or want automatic initialisation on library load. > > ok tb@ > This was discovered after investigating a diff by Viktor Szakats who tracked down strange crashes on MinGW when experimenting with CET on this platform to be related to an endbr64 in the .init section.
Re: CVS: cvs.openbsd.org: src
On Wed, Mar 27, 2024 at 11:35:01PM +0100, Alexander Bluhm wrote: > On Thu, Mar 28, 2024 at 01:21:17AM +0300, Vitaliy Makkoveev wrote: > > On Wed, Mar 27, 2024 at 10:51:09PM +0100, Alexander Bluhm wrote: > > > On Wed, Mar 27, 2024 at 10:26:27PM +0300, Vitaliy Makkoveev wrote: > > > > On Wed, Mar 27, 2024 at 08:17:33AM +0100, Anton Lindqvist wrote: > > > > > > > > > > Observing two regress hangs in the kernel on netio. Both seems make > > > > > use > > > > > of unix sockets. Could this be the culprit? > > > > > > > > > > regress/lib/libc/fread > > > > > regress/usr.bin/ssh (scp.sh) > > > > > > > > Sorry for delay. > > > > > > > > It was exposed that `sb_mtx' should not be released between `so_rcv' > > > > usage check and corresponding sbwait() sleep. Otherwise wakeup() could > > > > be lost sometimes. > > > > > > > > This diff fixed regress tests. It introduces sbunlock_locked() and > > > > sbwait_locked() to perform with `sb_mtx' held. > > > > > > Do we really need a restart_unlocked label? > > > Instead of goto restart_unlocked you could call solock_shared(so) > > > and fall through goto restart; > > > > > > > This was the first version, but later I decided 'restart_unlocked' is > > better. No problems to return it back. > > > > > I don't like pr_protocol == AF_UNIX check in generic soreceive() > > > function. Could we check SB_MTXLOCK instead? > > > > > > > Me too. I used "pr_protocol == AF_UNIX" check because sosend() does the > > same. The existing SB_MTXLOCK used by some inet sockets and I strictly > > want to move them separately of this fix. > > > > I propose to introduce SB_OWNLOCK flag and check it. I wanted to use > > this flag for socket with standalone sblock() ability to modify > > sblock()/sbwait() behaviour. I need this flag to convert all > > SB_MTXLOCK'ed sockets separately. After conversion, both SB_MTXLOCK and > > SB_OWNLOCK will be removed. > > > > I propose to introduce SB_OWNLOCK right now and use it instead of > > "pr_protocol == AF_UNIX" check to keep inet sockets as is. I have no > > objections to convert them too, but separately. > > sb_flags is short, can you use 4 digits 0x for the flags? > And please use a space after #define, then the diff is less ugly. > Done. Thanks.
Re: CVS: cvs.openbsd.org: src
On Thu, Mar 28, 2024 at 01:21:17AM +0300, Vitaliy Makkoveev wrote:
> On Wed, Mar 27, 2024 at 10:51:09PM +0100, Alexander Bluhm wrote:
> > On Wed, Mar 27, 2024 at 10:26:27PM +0300, Vitaliy Makkoveev wrote:
> > > On Wed, Mar 27, 2024 at 08:17:33AM +0100, Anton Lindqvist wrote:
> > > >
> > > > Observing two regress hangs in the kernel on netio. Both seems make use
> > > > of unix sockets. Could this be the culprit?
> > > >
> > > > regress/lib/libc/fread
> > > > regress/usr.bin/ssh (scp.sh)
> > >
> > > Sorry for delay.
> > >
> > > It was exposed that `sb_mtx' should not be released between `so_rcv'
> > > usage check and corresponding sbwait() sleep. Otherwise wakeup() could
> > > be lost sometimes.
> > >
> > > This diff fixed regress tests. It introduces sbunlock_locked() and
> > > sbwait_locked() to perform with `sb_mtx' held.
> >
> > Do we really need a restart_unlocked label?
> > Instead of goto restart_unlocked you could call solock_shared(so)
> > and fall through goto restart;
> >
>
> This was the first version, but later I decided 'restart_unlocked' is
> better. No problems to return it back.
>
> > I don't like pr_protocol == AF_UNIX check in generic soreceive()
> > function. Could we check SB_MTXLOCK instead?
> >
>
> Me too. I used "pr_protocol == AF_UNIX" check because sosend() does the
> same. The existing SB_MTXLOCK used by some inet sockets and I strictly
> want to move them separately of this fix.
>
> I propose to introduce SB_OWNLOCK flag and check it. I wanted to use
> this flag for socket with standalone sblock() ability to modify
> sblock()/sbwait() behaviour. I need this flag to convert all
> SB_MTXLOCK'ed sockets separately. After conversion, both SB_MTXLOCK and
> SB_OWNLOCK will be removed.
>
> I propose to introduce SB_OWNLOCK right now and use it instead of
> "pr_protocol == AF_UNIX" check to keep inet sockets as is. I have no
> objections to convert them too, but separately.
sb_flags is short, can you use 4 digits 0x for the flags?
And please use a space after #define, then the diff is less ugly.
OK bluhm@
> Index: sys/kern/uipc_socket.c
> ===
> RCS file: /cvs/src/sys/kern/uipc_socket.c,v
> retrieving revision 1.322
> diff -u -p -r1.322 uipc_socket.c
> --- sys/kern/uipc_socket.c26 Mar 2024 09:46:47 - 1.322
> +++ sys/kern/uipc_socket.c27 Mar 2024 22:12:55 -
> @@ -161,7 +161,7 @@ soalloc(const struct protosw *prp, int w
> }
> break;
> case AF_UNIX:
> - so->so_rcv.sb_flags |= SB_MTXLOCK;
> + so->so_rcv.sb_flags |= SB_MTXLOCK | SB_OWNLOCK;
> break;
> }
>
> @@ -903,12 +903,23 @@ restart:
> }
> SBLASTRECORDCHK(&so->so_rcv, "soreceive sbwait 1");
> SBLASTMBUFCHK(&so->so_rcv, "soreceive sbwait 1");
> - sb_mtx_unlock(&so->so_rcv);
> - sbunlock(so, &so->so_rcv);
> - error = sbwait(so, &so->so_rcv);
> - if (error) {
> +
> + if (so->so_rcv.sb_flags & SB_OWNLOCK) {
> + sbunlock_locked(so, &so->so_rcv);
> sounlock_shared(so);
> - return (error);
> + error = sbwait_locked(so, &so->so_rcv);
> + sb_mtx_unlock(&so->so_rcv);
> + if (error)
> + return (error);
> + solock_shared(so);
> + } else {
> + sb_mtx_unlock(&so->so_rcv);
> + sbunlock(so, &so->so_rcv);
> + error = sbwait(so, &so->so_rcv);
> + if (error) {
> + sounlock_shared(so);
> + return (error);
> + }
> }
> goto restart;
> }
> Index: sys/kern/uipc_socket2.c
> ===
> RCS file: /cvs/src/sys/kern/uipc_socket2.c,v
> retrieving revision 1.145
> diff -u -p -r1.145 uipc_socket2.c
> --- sys/kern/uipc_socket2.c 26 Mar 2024 09:46:47 - 1.145
> +++ sys/kern/uipc_socket2.c 27 Mar 2024 22:12:55 -
> @@ -523,6 +523,18 @@ sbmtxassertlocked(struct socket *so, str
> * Wait for data to arrive at/drain from a socket buffer.
> */
> int
> +sbwait_locked(struct socket *so, struct sockbuf *sb)
> +{
> + int prio = (sb->sb_flags & SB_NOINTR) ? PSOCK : PSOCK | PCATCH;
> +
> + MUTEX_ASSERT_LOCKED(&sb->sb_mtx);
> +
> + sb->sb_flags |= SB_WAIT;
> + return msleep_nsec(&sb->sb_cc, &sb->sb_mtx, prio, "sbwait",
> + sb->sb_timeo_nsecs);
> +}
> +
> +int
> sbwait(struct socket *so, struct sockbuf *sb)
> {
> uint64_t timeo_nsecs;
> @@ -573,20 +585,23 @@ out:
> }
>
> void
> -sbunlock(struct socket *so, struct sockbuf *sb)
> +sbunlock_locked(struct socket *so, struct sockbuf *sb)
> {
> - int dowakeup = 0;
> + MUTEX_ASSERT_LOCKED(&s
Re: CVS: cvs.openbsd.org: src
On Wed, Mar 27, 2024 at 10:51:09PM +0100, Alexander Bluhm wrote:
> On Wed, Mar 27, 2024 at 10:26:27PM +0300, Vitaliy Makkoveev wrote:
> > On Wed, Mar 27, 2024 at 08:17:33AM +0100, Anton Lindqvist wrote:
> > >
> > > Observing two regress hangs in the kernel on netio. Both seems make use
> > > of unix sockets. Could this be the culprit?
> > >
> > > regress/lib/libc/fread
> > > regress/usr.bin/ssh (scp.sh)
> >
> > Sorry for delay.
> >
> > It was exposed that `sb_mtx' should not be released between `so_rcv'
> > usage check and corresponding sbwait() sleep. Otherwise wakeup() could
> > be lost sometimes.
> >
> > This diff fixed regress tests. It introduces sbunlock_locked() and
> > sbwait_locked() to perform with `sb_mtx' held.
>
> Do we really need a restart_unlocked label?
> Instead of goto restart_unlocked you could call solock_shared(so)
> and fall through goto restart;
>
This was the first version, but later I decided 'restart_unlocked' is
better. No problems to return it back.
> I don't like pr_protocol == AF_UNIX check in generic soreceive()
> function. Could we check SB_MTXLOCK instead?
>
Me too. I used "pr_protocol == AF_UNIX" check because sosend() does the
same. The existing SB_MTXLOCK used by some inet sockets and I strictly
want to move them separately of this fix.
I propose to introduce SB_OWNLOCK flag and check it. I wanted to use
this flag for socket with standalone sblock() ability to modify
sblock()/sbwait() behaviour. I need this flag to convert all
SB_MTXLOCK'ed sockets separately. After conversion, both SB_MTXLOCK and
SB_OWNLOCK will be removed.
I propose to introduce SB_OWNLOCK right now and use it instead of
"pr_protocol == AF_UNIX" check to keep inet sockets as is. I have no
objections to convert them too, but separately.
Index: sys/kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.322
diff -u -p -r1.322 uipc_socket.c
--- sys/kern/uipc_socket.c 26 Mar 2024 09:46:47 - 1.322
+++ sys/kern/uipc_socket.c 27 Mar 2024 22:12:55 -
@@ -161,7 +161,7 @@ soalloc(const struct protosw *prp, int w
}
break;
case AF_UNIX:
- so->so_rcv.sb_flags |= SB_MTXLOCK;
+ so->so_rcv.sb_flags |= SB_MTXLOCK | SB_OWNLOCK;
break;
}
@@ -903,12 +903,23 @@ restart:
}
SBLASTRECORDCHK(&so->so_rcv, "soreceive sbwait 1");
SBLASTMBUFCHK(&so->so_rcv, "soreceive sbwait 1");
- sb_mtx_unlock(&so->so_rcv);
- sbunlock(so, &so->so_rcv);
- error = sbwait(so, &so->so_rcv);
- if (error) {
+
+ if (so->so_rcv.sb_flags & SB_OWNLOCK) {
+ sbunlock_locked(so, &so->so_rcv);
sounlock_shared(so);
- return (error);
+ error = sbwait_locked(so, &so->so_rcv);
+ sb_mtx_unlock(&so->so_rcv);
+ if (error)
+ return (error);
+ solock_shared(so);
+ } else {
+ sb_mtx_unlock(&so->so_rcv);
+ sbunlock(so, &so->so_rcv);
+ error = sbwait(so, &so->so_rcv);
+ if (error) {
+ sounlock_shared(so);
+ return (error);
+ }
}
goto restart;
}
Index: sys/kern/uipc_socket2.c
===
RCS file: /cvs/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.145
diff -u -p -r1.145 uipc_socket2.c
--- sys/kern/uipc_socket2.c 26 Mar 2024 09:46:47 - 1.145
+++ sys/kern/uipc_socket2.c 27 Mar 2024 22:12:55 -
@@ -523,6 +523,18 @@ sbmtxassertlocked(struct socket *so, str
* Wait for data to arrive at/drain from a socket buffer.
*/
int
+sbwait_locked(struct socket *so, struct sockbuf *sb)
+{
+ int prio = (sb->sb_flags & SB_NOINTR) ? PSOCK : PSOCK | PCATCH;
+
+ MUTEX_ASSERT_LOCKED(&sb->sb_mtx);
+
+ sb->sb_flags |= SB_WAIT;
+ return msleep_nsec(&sb->sb_cc, &sb->sb_mtx, prio, "sbwait",
+ sb->sb_timeo_nsecs);
+}
+
+int
sbwait(struct socket *so, struct sockbuf *sb)
{
uint64_t timeo_nsecs;
@@ -573,20 +585,23 @@ out:
}
void
-sbunlock(struct socket *so, struct sockbuf *sb)
+sbunlock_locked(struct socket *so, struct sockbuf *sb)
{
- int dowakeup = 0;
+ MUTEX_ASSERT_LOCKED(&sb->sb_mtx);
- mtx_enter(&sb->sb_mtx);
sb->sb_flags &= ~SB_LOCK;
if (sb->sb_flags & SB_WANT) {
sb->sb_flags &= ~SB_WANT;
- dowakeup = 1;
+ wakeup(&sb->sb_flags);
}
- mtx_leave(&sb->sb_mtx);
+}
- if (dowakeup)
- wakeup(&sb->sb_flags);
+void
+sb
Re: CVS: cvs.openbsd.org: src
On Wed, Mar 27, 2024 at 10:26:27PM +0300, Vitaliy Makkoveev wrote:
> On Wed, Mar 27, 2024 at 08:17:33AM +0100, Anton Lindqvist wrote:
> >
> > Observing two regress hangs in the kernel on netio. Both seems make use
> > of unix sockets. Could this be the culprit?
> >
> > regress/lib/libc/fread
> > regress/usr.bin/ssh (scp.sh)
>
> Sorry for delay.
>
> It was exposed that `sb_mtx' should not be released between `so_rcv'
> usage check and corresponding sbwait() sleep. Otherwise wakeup() could
> be lost sometimes.
>
> This diff fixed regress tests. It introduces sbunlock_locked() and
> sbwait_locked() to perform with `sb_mtx' held.
Do we really need a restart_unlocked label?
Instead of goto restart_unlocked you could call solock_shared(so)
and fall through goto restart;
I don't like pr_protocol == AF_UNIX check in generic soreceive()
function. Could we check SB_MTXLOCK instead?
bluhm
> Index: sys/kern/uipc_socket.c
> ===
> RCS file: /cvs/src/sys/kern/uipc_socket.c,v
> retrieving revision 1.322
> diff -u -p -r1.322 uipc_socket.c
> --- sys/kern/uipc_socket.c26 Mar 2024 09:46:47 - 1.322
> +++ sys/kern/uipc_socket.c27 Mar 2024 19:17:52 -
> @@ -834,6 +834,7 @@ bad:
> if (mp)
> *mp = NULL;
>
> +restart_unlocked:
> solock_shared(so);
> restart:
> if ((error = sblock(so, &so->so_rcv, SBLOCKWAIT(flags))) != 0) {
> @@ -903,12 +904,23 @@ restart:
> }
> SBLASTRECORDCHK(&so->so_rcv, "soreceive sbwait 1");
> SBLASTMBUFCHK(&so->so_rcv, "soreceive sbwait 1");
> - sb_mtx_unlock(&so->so_rcv);
> - sbunlock(so, &so->so_rcv);
> - error = sbwait(so, &so->so_rcv);
> - if (error) {
> +
> + if (so->so_proto->pr_protocol == AF_UNIX) {
> + sbunlock_locked(so, &so->so_rcv);
> sounlock_shared(so);
> - return (error);
> + error = sbwait_locked(so, &so->so_rcv);
> + sb_mtx_unlock(&so->so_rcv);
> + if (error)
> + return (error);
> + goto restart_unlocked;
> + } else {
> + sb_mtx_unlock(&so->so_rcv);
> + sbunlock(so, &so->so_rcv);
> + error = sbwait(so, &so->so_rcv);
> + if (error) {
> + sounlock_shared(so);
> + return (error);
> + }
> }
> goto restart;
> }
> Index: sys/kern/uipc_socket2.c
> ===
> RCS file: /cvs/src/sys/kern/uipc_socket2.c,v
> retrieving revision 1.145
> diff -u -p -r1.145 uipc_socket2.c
> --- sys/kern/uipc_socket2.c 26 Mar 2024 09:46:47 - 1.145
> +++ sys/kern/uipc_socket2.c 27 Mar 2024 19:17:52 -
> @@ -523,6 +523,18 @@ sbmtxassertlocked(struct socket *so, str
> * Wait for data to arrive at/drain from a socket buffer.
> */
> int
> +sbwait_locked(struct socket *so, struct sockbuf *sb)
> +{
> + int prio = (sb->sb_flags & SB_NOINTR) ? PSOCK : PSOCK | PCATCH;
> +
> + MUTEX_ASSERT_LOCKED(&sb->sb_mtx);
> +
> + sb->sb_flags |= SB_WAIT;
> + return msleep_nsec(&sb->sb_cc, &sb->sb_mtx, prio, "sbwait",
> + sb->sb_timeo_nsecs);
> +}
> +
> +int
> sbwait(struct socket *so, struct sockbuf *sb)
> {
> uint64_t timeo_nsecs;
> @@ -573,20 +585,23 @@ out:
> }
>
> void
> -sbunlock(struct socket *so, struct sockbuf *sb)
> +sbunlock_locked(struct socket *so, struct sockbuf *sb)
> {
> - int dowakeup = 0;
> + MUTEX_ASSERT_LOCKED(&sb->sb_mtx);
>
> - mtx_enter(&sb->sb_mtx);
> sb->sb_flags &= ~SB_LOCK;
> if (sb->sb_flags & SB_WANT) {
> sb->sb_flags &= ~SB_WANT;
> - dowakeup = 1;
> + wakeup(&sb->sb_flags);
> }
> - mtx_leave(&sb->sb_mtx);
> +}
>
> - if (dowakeup)
> - wakeup(&sb->sb_flags);
> +void
> +sbunlock(struct socket *so, struct sockbuf *sb)
> +{
> + mtx_enter(&sb->sb_mtx);
> + sbunlock_locked(so, sb);
> + mtx_leave(&sb->sb_mtx);
> }
>
> /*
> Index: sys/sys/socketvar.h
> ===
> RCS file: /cvs/src/sys/sys/socketvar.h,v
> retrieving revision 1.126
> diff -u -p -r1.126 socketvar.h
> --- sys/sys/socketvar.h 26 Mar 2024 09:46:47 - 1.126
> +++ sys/sys/socketvar.h 27 Mar 2024 19:17:53 -
> @@ -320,6 +320,7 @@ int sblock(struct socket *, struct sockb
>
> /* release lock on sockbuf sb */
> void sbunlock(struct socket *, struct sockbuf *);
> +void sbunlock_locked(struct socket *, struct sockbuf *);
>
> #define SB_EMPTY_FIXUP(sb) do {
> \
> if ((sb)->sb_mb == NULL) { \
> @@ -367,6 +3
Re: CVS: cvs.openbsd.org: src
On Wed, Mar 27, 2024 at 08:17:33AM +0100, Anton Lindqvist wrote:
>
> Observing two regress hangs in the kernel on netio. Both seems make use
> of unix sockets. Could this be the culprit?
>
> regress/lib/libc/fread
> regress/usr.bin/ssh (scp.sh)
Sorry for delay.
It was exposed that `sb_mtx' should not be released between `so_rcv'
usage check and corresponding sbwait() sleep. Otherwise wakeup() could
be lost sometimes.
This diff fixed regress tests. It introduces sbunlock_locked() and
sbwait_locked() to perform with `sb_mtx' held.
Index: sys/kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.322
diff -u -p -r1.322 uipc_socket.c
--- sys/kern/uipc_socket.c 26 Mar 2024 09:46:47 - 1.322
+++ sys/kern/uipc_socket.c 27 Mar 2024 19:17:52 -
@@ -834,6 +834,7 @@ bad:
if (mp)
*mp = NULL;
+restart_unlocked:
solock_shared(so);
restart:
if ((error = sblock(so, &so->so_rcv, SBLOCKWAIT(flags))) != 0) {
@@ -903,12 +904,23 @@ restart:
}
SBLASTRECORDCHK(&so->so_rcv, "soreceive sbwait 1");
SBLASTMBUFCHK(&so->so_rcv, "soreceive sbwait 1");
- sb_mtx_unlock(&so->so_rcv);
- sbunlock(so, &so->so_rcv);
- error = sbwait(so, &so->so_rcv);
- if (error) {
+
+ if (so->so_proto->pr_protocol == AF_UNIX) {
+ sbunlock_locked(so, &so->so_rcv);
sounlock_shared(so);
- return (error);
+ error = sbwait_locked(so, &so->so_rcv);
+ sb_mtx_unlock(&so->so_rcv);
+ if (error)
+ return (error);
+ goto restart_unlocked;
+ } else {
+ sb_mtx_unlock(&so->so_rcv);
+ sbunlock(so, &so->so_rcv);
+ error = sbwait(so, &so->so_rcv);
+ if (error) {
+ sounlock_shared(so);
+ return (error);
+ }
}
goto restart;
}
Index: sys/kern/uipc_socket2.c
===
RCS file: /cvs/src/sys/kern/uipc_socket2.c,v
retrieving revision 1.145
diff -u -p -r1.145 uipc_socket2.c
--- sys/kern/uipc_socket2.c 26 Mar 2024 09:46:47 - 1.145
+++ sys/kern/uipc_socket2.c 27 Mar 2024 19:17:52 -
@@ -523,6 +523,18 @@ sbmtxassertlocked(struct socket *so, str
* Wait for data to arrive at/drain from a socket buffer.
*/
int
+sbwait_locked(struct socket *so, struct sockbuf *sb)
+{
+ int prio = (sb->sb_flags & SB_NOINTR) ? PSOCK : PSOCK | PCATCH;
+
+ MUTEX_ASSERT_LOCKED(&sb->sb_mtx);
+
+ sb->sb_flags |= SB_WAIT;
+ return msleep_nsec(&sb->sb_cc, &sb->sb_mtx, prio, "sbwait",
+ sb->sb_timeo_nsecs);
+}
+
+int
sbwait(struct socket *so, struct sockbuf *sb)
{
uint64_t timeo_nsecs;
@@ -573,20 +585,23 @@ out:
}
void
-sbunlock(struct socket *so, struct sockbuf *sb)
+sbunlock_locked(struct socket *so, struct sockbuf *sb)
{
- int dowakeup = 0;
+ MUTEX_ASSERT_LOCKED(&sb->sb_mtx);
- mtx_enter(&sb->sb_mtx);
sb->sb_flags &= ~SB_LOCK;
if (sb->sb_flags & SB_WANT) {
sb->sb_flags &= ~SB_WANT;
- dowakeup = 1;
+ wakeup(&sb->sb_flags);
}
- mtx_leave(&sb->sb_mtx);
+}
- if (dowakeup)
- wakeup(&sb->sb_flags);
+void
+sbunlock(struct socket *so, struct sockbuf *sb)
+{
+ mtx_enter(&sb->sb_mtx);
+ sbunlock_locked(so, sb);
+ mtx_leave(&sb->sb_mtx);
}
/*
Index: sys/sys/socketvar.h
===
RCS file: /cvs/src/sys/sys/socketvar.h,v
retrieving revision 1.126
diff -u -p -r1.126 socketvar.h
--- sys/sys/socketvar.h 26 Mar 2024 09:46:47 - 1.126
+++ sys/sys/socketvar.h 27 Mar 2024 19:17:53 -
@@ -320,6 +320,7 @@ int sblock(struct socket *, struct sockb
/* release lock on sockbuf sb */
void sbunlock(struct socket *, struct sockbuf *);
+void sbunlock_locked(struct socket *, struct sockbuf *);
#defineSB_EMPTY_FIXUP(sb) do {
\
if ((sb)->sb_mb == NULL) { \
@@ -367,6 +368,7 @@ int sbcheckreserve(u_long, u_long);
intsbchecklowmem(void);
intsbreserve(struct socket *, struct sockbuf *, u_long);
intsbwait(struct socket *, struct sockbuf *);
+intsbwait_locked(struct socket *, struct sockbuf *);
void soinit(void);
void soabort(struct socket *);
intsoaccept(struct socket *, struct mbuf *);
Re: CVS: cvs.openbsd.org: src
On Tue, Mar 26, 2024 at 03:46:47AM -0600, Vitaliy Makkoveev wrote: > CVSROOT: /cvs > Module name: src > Changes by: m...@cvs.openbsd.org2024/03/26 03:46:47 > > Modified files: > sys/kern : sys_socket.c uipc_socket.c uipc_socket2.c >uipc_usrreq.c > sys/miscfs/fifofs: fifo_vnops.c > sys/sys: socketvar.h > > Log message: > Use `sb_mtx' to protect `so_rcv' receive buffer of unix(4) sockets. > > This makes re-locking unnecessary in the uipc_*send() paths, because > it's enough to lock one socket to prevent peer from concurrent > disconnection. As the little bonus, one unix(4) socket can perform > simultaneous transmission and reception with one exception for > uipc_rcvd(), which still requires the re-lock for connection oriented > sockets. > > The socket lock is not held while filt_soread() and filt_soexcept() > called from uipc_*send() through sorwakeup(). However, the unlocked > access to the `so_options', `so_state' and `so_error' is fine. > > The receiving socket can't be or became listening socket. It also can't > be disconnected concurrently. This makes immutable SO_ACCEPTCONN, > SS_ISDISCONNECTED and SS_ISCONNECTED bits which are clean and set > respectively. > > `so_error' is set on the peer sockets only by unp_detach(), which also > can't be called concurrently on sending socket. > > This is also true for filt_fiforead() and filt_fifoexcept(). For other > callers like kevent(2) or doaccept() the socket lock is still held. > > ok bluhm Observing two regress hangs in the kernel on netio. Both seems make use of unix sockets. Could this be the culprit? regress/lib/libc/fread regress/usr.bin/ssh (scp.sh)
Re: CVS: cvs.openbsd.org: src
Should it be removed from changelist too? On 2024/03/15 23:18, Job Snijders wrote: > CVSROOT: /cvs > Module name: src > Changes by: j...@cvs.openbsd.org2024/03/15 23:18:01 > > Modified files: > distrib/sets/lists/base: mi > distrib/sets/lists/etc: mi > > Log message: > Move RPKI Trust Anchor constraints from etc set to base > > The cadence of updates being applied to the RPKI Trust Anchor constraints > seems sufficiently low, while the required understanding of context to make > educated decisions quite high, so centralized coordination of updates through > t...@openbsd.org is more appropriate. > > requested by & OK deraadt@, OK tb@ >
Re: CVS: cvs.openbsd.org: src
On Fri, Mar 01, 2024 at 01:10:09AM -0700, Theo Buehler wrote: > CVSROOT: /cvs > Module name: src > Changes by: t...@cvs.openbsd.org2024/03/01 01:10:09 > > Modified files: > usr.sbin/rpki-client: main.c output-json.c parser.c > rpki-client.8 > > Log message: > Add -x to opt into experimental file formats > > Instead of burning one letter for each new file format (sidrops is known > to crank out new things faster than a normal person can read), use -x to > opt into parsing and processing file formats that aren't yet considered > stable. This is currently only the Signed Prefix List. While a repetition > of the ASPA debacle, this code hasn't yet seen enough stress testing to be > enabled by default. This should have said: "while a repetition of the ASPA debacle is unlikely". > > ok claudio job >
Re: CVS: cvs.openbsd.org: src
Alexander Bluhm: > CVSROOT: /cvs > Module name: src > Changes by: bl...@cvs.openbsd.org 2024/02/27 05:37:49 > > Modified files: > sys/net: route.c route.h > sys/netinet: in_pcb.c > sys/netinet6 : in6_pcb.c in6_src.c > > Log message: > Combine route_cache() and rtalloc_mpath() in new route_mpath(). > > Fill and check the cache and call rtalloc_mpath() together. Then > the caller of route_mpath() does not have to care about the uint32_t > *src pointer and just pass struct in_addr. All the conversions are > done inside the functions. ro->ro_rt is either valid or NULL. Note > that some places have a stricter rtisvalid() now compared to the > previous NULL check. > > OK claudio@ This change breaks NFS in some way: starting RPC daemons: portmap mountd nfsd. NFS Portmap: RPC: Port mapper failure - RPC: Unable to send NFS Portmap: RPC: Port mapper failure - RPC: Unable to send NFS Portmap: RPC: Port mapper failure - RPC: Unable to send NFS Portmap: RPC: Port mapper failure - RPC: Unable to send NFS Portmap: RPC: Port mapper failure - RPC: Unable to send -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: CVS: cvs.openbsd.org: src
David Gwynne wrote: > CVSROOT: /cvs > Module name: src > Changes by: d...@cvs.openbsd.org2024/02/20 18:45:14 > > Modified files: > sys/arch/riscv64/riscv64: machdep.c > sys/arch/arm64/arm64: machdep.c > > Log message: > handle /reserved-memory nodes from device trees on arm64. > > u-boot is supposed to take these entries and put them in the efi > memory map, but i keep hitting machines where an otherwise functional > u-boot does not do this, resulting in weird errors. > > i have an espressobin with a vendor u-boot that has a reserved-memory > region for psci. without this diff the machine faults when the > kernel tries to reboot using a psci handler. > > a macchiatobin with an otherwise working u-boot throws SErrors or > panics on weird memory corruption problems without this. i thought > it was bad RAM, but the problems persisted with completely different > ram, and very underclocked and well cooled ram. > > riscv64 already has code to handle reserved-memory regions. the > riscv64 change is to add handling for the "no-map" property. This locks up the kernel on riscv64 Unmatched: After Copyright, but before printing OpenBSD 7.5...
Re: CVS: cvs.openbsd.org: src
February 19, 2024 10:00 PM, "Gilles Chehade" wrote: > CVSROOT: /cvs > Module name: src > Changes by: gil...@cvs.openbsd.org 2024/02/19 14:00:19 > > Modified files: > usr.sbin/smtpd : parse.y > > Log message: > no need to be as strict with table formats on various match constraints, > this prevents the reuse of T_HASH tables in T_LIST contexts when the key > column actually makes sense by itself. > > diff from Philipp (philipp+openbsd [at] bureaucracy [dot] de) sorry, this was ok op@
Re: CVS: cvs.openbsd.org: src
On Thu, Feb 15, 2024 at 03:56:53AM -0700, Marcus Glocker wrote: > CVSROOT: /cvs > Module name: src > Changes by: mgloc...@cvs.openbsd.org2024/02/15 03:56:53 > > Modified files: > sys/dev/pci: if_ix.c > > Log message: > Fix bogus packet length calculation in the RX/LRO path, which can lead to > TSO tagging forwarded packets which shouldn't. This will also fix the em(4) > watchdog timeouts seen after the em(4) TSO commit. > > Thanks to Hrvoje Popovski for providing the infrastructure the reproduce > the issue, and test the fix. > > Discussed with bluhm@. OK claudio@ And OK bluhm@
Re: CVS: cvs.openbsd.org: src
On Fri, Feb 02, 2024 at 08:39:23AM -0700, Alexander Bluhm wrote: > CVSROOT: /cvs > Module name: src > Changes by: bl...@cvs.openbsd.org 2024/02/02 08:39:23 > > Modified files: > sys/netinet: in_pcb.c > > Log message: > In in_pcbrtentry() add missing return of in6_pcbrtentry() value. > > Reported-by: syzbot+5f2286d5962355f0c...@syzkaller.appspotmail.com > OK kn@ and OK claudio@
Re: CVS: cvs.openbsd.org: src
On Tue, Jan 16, 2024 at 06:33:13AM -0700, Claudio Jeker wrote: > CVSROOT: /cvs > Module name: src > Changes by: clau...@cvs.openbsd.org 2024/01/16 06:33:13 > > Modified files: > usr.sbin/snmpd : proc.c snmpd.h snmpe.c > > Log message: > Convert to imsg_get_fd() and remove unused proc_forward_imsg(). > OK martijn@ > Also OK florian@ -- :wq Claudio
Re: CVS: cvs.openbsd.org: src
>However, to ease this transition, change ld.so to only load the first libc >version that we encounter (in a breadth first sense) and substitute that >libc version for all further loads of libc, even if different versions are >requested. This is done silently since I can't come up with a good warning >message. In practice this means the libc version requested by the >executable itself will be loaded. This means that shared libraries may >fail to load if they use a symbol that has been removed. But given the >constraints, this is the best that we can do. Even when we bump the >libc major, the set of changes is typically small and most binaries and >shared libraries will continue to run and allow the user to run pkg_add -u >without any fallout. When there are API additions and deletions, we tend to be pretty careful. Meaning, additions tend to happen well in advance of deletions. I've done a vague retrospective inspection of this, and it looks like we would not have been negatively affected in the last 4 years, during a 6-month window. Maybe we can be more careful. Generally, anyone doing a development that will remove an API is going to hit the issue first by themselves. And I think it will be more a more obvious failure for that developer now, than it was in the past. So this behaviour is probably an improvement.
Re: CVS: cvs.openbsd.org: src
On Sat, Jan 06, 2024 at 04:29:00AM -0700, Marc Espie wrote: > CVSROOT: /cvs > Module name: src > Changes by: es...@cvs.openbsd.org 2024/01/06 04:29:00 > > Modified files: > usr.sbin/httpd : js.h.in server_file.c > > Log message: > put the real sizes into the "title" attribute so that hovering shows the > exact value. > > adjust/refactor javascript sorter accordingly > > Forgot to say this was okay tb@
Re: CVS: cvs.openbsd.org: src
On Wed, Jan 03, 2024 at 02:19:22AM -0700, Kevin Lo wrote: > > CVSROOT: /cvs > Module name: src > Changes by: ke...@cvs.openbsd.org 2024/01/03 02:19:22 > > Modified files: > share/man/man4 : uoaklux.4 uoakrh.4 uoakv.4 > > Log message: > Update website URL. > > ok miod@ Also ok sthen@
Re: CVS: cvs.openbsd.org: src
On Sat, 23 Dec 2023 09:05:54 +0100, Anton Lindqvist wrote: > On Fri, Dec 22, 2023 at 10:12:13AM -0700, Todd C. Miller wrote: > > CVSROOT:/cvs > > Module name:src > > Changes by: mill...@cvs.openbsd.org 2023/12/22 10:12:13 > > > > Modified files: > > regress/usr.bin/xargs: xargs-L.sh > > usr.bin/xargs : xargs.c > > > > Log message: > > xargs: fix parsing of empty fields when "xargs -0" is used. > > Previously, these fields would be skipped. From Hiltjo Posthuma. > > This broke the common `find -print0 | xargs -0` idiom: > > $ mkdir -p /tmp/a > $ find /tmp/a -print0 | xargs -0r rm -r > rm: : No such file or directory Thanks, this should be fixed now. - todd
Re: CVS: cvs.openbsd.org: src
> On 23 Dec 2023, at 13:15, Alexander Bluhm wrote: > > On Fri, Dec 22, 2023 at 04:01:50PM -0700, Vitaliy Makkoveev wrote: >> CVSROOT: /cvs >> Module name: src >> Changes by: m...@cvs.openbsd.org2023/12/22 16:01:50 >> >> Modified files: >> sys/net: if.c if_aggr.c if_bpe.c if_etherip.c if_gif.c >> if_gre.c if_mpe.c if_mpip.c if_mpw.c if_pflow.c >> if_pfsync.c if_pppx.c if_sec.c if_tpmr.c >> if_trunk.c if_tun.c if_var.h if_veb.c if_vlan.c >> if_vxlan.c if_wg.c >> sys/netinet: ip_carp.c >> >> Log message: >> Always allocate per-CPU statistics counters for network interface >> descriptor. > > It looks like this breaks interface attach. > It should be backed out. > Thanks for backout and sorry for delay.
Re: CVS: cvs.openbsd.org: src
On Fri, Dec 22, 2023 at 04:01:50PM -0700, Vitaliy Makkoveev wrote: > CVSROOT: /cvs > Module name: src > Changes by: m...@cvs.openbsd.org2023/12/22 16:01:50 > > Modified files: > sys/net: if.c if_aggr.c if_bpe.c if_etherip.c if_gif.c >if_gre.c if_mpe.c if_mpip.c if_mpw.c if_pflow.c >if_pfsync.c if_pppx.c if_sec.c if_tpmr.c >if_trunk.c if_tun.c if_var.h if_veb.c if_vlan.c >if_vxlan.c if_wg.c > sys/netinet: ip_carp.c > > Log message: > Always allocate per-CPU statistics counters for network interface > descriptor. It looks like this breaks interface attach. It should be backed out. bluhm pci4 at ppb3 bus 4 em0 at pci4 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 8 int 17uvm_fault(0 x824bf360, 0x8, 0, 1) -> e kernel: page fault trap, code=0 Stopped at pool_get+0x6e: movq0x8(%rax),%r11 TIDPIDUID PRFLAGS PFLAGS CPU COMMAND * 0 0 0 0x1 0x2000K swapper pool_get(825aac78,1,a619daefe381a0c,8017a048,d,8017a7e8 ) at pool_get+0x6e counters_alloc(c,c,a1f03e534e639ae1,8017a048,8017a048,8 017a7e8) at counters_alloc+0x3f if_attach_common(8017a048,8017a048,ce773033c5bc7a4c,801 7a048,8017a048,e) at if_attach_common+0xa7 if_attach(8017a048,8017a048,8017a000,e,81618525 ,8295be70) at if_attach+0x15 em_setup_interface(8017a000,8017a000,8017a578,8 017a000,8017a548,0) at em_setup_interface+0x1c8 em_attach(80177900,8017a000,8295bfa8,80177900,b d8850f5395a4cef,80177900) at em_attach+0x410 config_attach(80177900,8245e5a8,8295bfa8,81b39c 50,e47e39a69ab854bf,8004) at config_attach+0x1e2 pci_probe_device(80177900,8004,0,0,e374438be72c4e6d,0) at pci_probe _device+0x4c4 pci_enumerate_bus(80177900,0,0,80177900,f5afadb07e1609f4,80 179000) at pci_enumerate_bus+0x183 config_attach(80179000,8245d9d8,8295c1d0,82037f 00,e47e39a699089b75,8295c348) at config_attach+0x1e2 ppbattach(80177700,80179000,8295c348,80177700,f 7ff70c80a4ae9eb,80177700) at ppbattach+0x74e config_attach(80177700,8245e2d0,8295c348,81b39c 50,e47e39a69ab854bf,80020800) at config_attach+0x1e2 pci_probe_device(80177700,80020800,0,0,e374438be72c4e6d,0) at pci_probe _device+0x4c4 pci_enumerate_bus(80177700,0,0,80177700,f5afadb07e1609f4,80 178800) at pci_enumerate_bus+0x183 end trace frame: 0x8295c550, count: 0 > We have the mess in network interface statistics. Only pseudo drivers > do per-CPU counters allocation, all other network devices use the old > `if_data'. The network stack partially uses per-CPU counters and > partially use `if_data', but the protection is inconsistent: some times > counters accessed with exclusive netlock, some times with shared > netlock, some times with kernel lock, but without netlock, some times > with another locks. > > To make network interfaces statistics more consistent, always allocate > per-CPU counters at interface attachment time and use it instead of > `if_data'. At this step only move counters allocation to the if_attach() > internals. The `if_data' removal will be performed with the following > diffs to make review and tests easier. > > ok bluhm
Re: CVS: cvs.openbsd.org: src
On Fri, Dec 22, 2023 at 10:12:13AM -0700, Todd C. Miller wrote: > CVSROOT: /cvs > Module name: src > Changes by: mill...@cvs.openbsd.org 2023/12/22 10:12:13 > > Modified files: > regress/usr.bin/xargs: xargs-L.sh > usr.bin/xargs : xargs.c > > Log message: > xargs: fix parsing of empty fields when "xargs -0" is used. > Previously, these fields would be skipped. From Hiltjo Posthuma. This broke the common `find -print0 | xargs -0` idiom: $ mkdir -p /tmp/a $ find /tmp/a -print0 | xargs -0r rm -r rm: : No such file or directory
Re: CVS: cvs.openbsd.org: src
On 2023/12/04 07:24, Robert Nagy wrote: > CVSROOT: /cvs > Module name: src > Changes by: rob...@cvs.openbsd.org 2023/12/04 07:24:29 > > Modified files: > gnu/llvm/lld/ELF: InputFiles.cpp Relocations.cpp > > Log message: > protect access to the gnu warning map with a mutex to avoid random crashes > > discussed with, tested by and ok tb@ > (seen fairly frequently with -static)
Re: CVS: cvs.openbsd.org: src
And ok miod@
> ROOT: /cvs
> Module name: src
> Changes by: mgloc...@cvs.openbsd.org2023/12/03 22:28:25
>
> Modified files:
> sys/dev/usb: uthum.c
>
> Log message:
> Make the TEMPer{1,2} devices display minus degC. From the NetBSD driver.
>
> ok deraadt@
Re: CVS: cvs.openbsd.org: src
On Tue, Nov 21, 2023 at 09:21:03AM +0100, Florian Obser wrote:
> On 2023-11-21 08:04 +01, Anton Lindqvist wrote:
> > On Mon, Nov 20, 2023 at 05:15:16AM -0700, Florian Obser wrote:
> >> CVSROOT: /cvs
> >> Module name: src
> >> Changes by:flor...@cvs.openbsd.org 2023/11/20 05:15:16
> >>
> >> Modified files:
> >>lib/libc/asr : asr_private.h asr_utils.c getaddrinfo_async.c
> >> gethostnamadr_async.c
> >>
> >> Log message:
> >> localhost is either 127.0.0.1 or ::1, nothing else.
> >>
> >> RFC 6761, 6.3 Domain Name Reservation Considerations for "localhost.":
> >> 3. Name resolution APIs and libraries SHOULD recognize localhost
> >> names as special and SHOULD always return the IP loopback address
> >> for address queries and negative responses for all other query
> >> types. Name resolution APIs SHOULD NOT send queries for
> >> localhost names to their configured caching DNS server(s).
> >>
> >> This makes sure that the getaddrinfo(3) and gethostbyname(3) family of
> >> functions always return the loopback address and do not send queries
> >> to name servers. This includes "localhost", "localhost." and
> >> everything under ".localhost" and ".localhost.".
> >>
> >> For example, a host underneath the .com.ar zone will per default have
> >> a search list of "com.ar.". resolv.conf(5) has a default of "lookup
> >> bind file". Both combined will result in lookups for "localhost" to
> >> not return 127.0.0.1 because localhost.com.ar is registered in DNS.
> >>
> >> It has been known for decades that this is a problem, especially for
> >> localhost.
> >>
> >> Problem recently spotted by gonzalo@ and debugged by sthen@
> >>
> >> Testing sthen, gonzalo
> >> Input & OK phessler, eric, millert
> >> OK sthen, kn, deraadt
> >
> > Seeing two new failures. The offending pf rule:
> >
> > pass in inet6 proto tcp to port 25 divert-to localhost port 8025
> >
> > pfctl complains about:
> >
> > stdin:10: divert-to address family mismatch
> >
> > Changing localhost to ::1 makes it pass again. Is this expected or a
> > regression? The ipsecctl failure looks like a symptom of the same
> > problem.
>
> We were a bit too enthusiastic short-circuiting "localhost". It has to
> fail if AI_NUMERICHOST is set, because "localhost" is not an IP address.
>
> This makes the pfctl and ipsecctl regress tests pass again. (At least
> with a non-weird /etc/resolv.conf).
>
> OK?
Fixes the tests here as well; ok anton@ FWIW
> diff --git getaddrinfo_async.c getaddrinfo_async.c
> index f85d541398a..2e5898b6411 100644
> --- getaddrinfo_async.c
> +++ getaddrinfo_async.c
> @@ -115,7 +115,7 @@ getaddrinfo_async_run(struct asr_query *as, struct
> asr_result *ar)
> char fqdn[MAXDNAME];
> const char *str;
> struct addrinfo *ai;
> - int i, family, r, is_localhost;
> + int i, family, r, is_localhost = 0;
> FILE*f;
> union {
> struct sockaddr sa;
> @@ -228,7 +228,8 @@ getaddrinfo_async_run(struct asr_query *as, struct
> asr_result *ar)
>
> ar->ar_gai_errno = 0;
>
> - is_localhost = _asr_is_localhost(as->as.ai.hostname);
> + if (!(ai->ai_flags & AI_NUMERICHOST))
> + is_localhost = _asr_is_localhost(as->as.ai.hostname);
> /*
>* If hostname is NULL, "localhost" or falls within the
>* ".localhost." domain, use local address.
>
>
> >
> >> sbin/ipsecctl
> > Exit: 1
> > Duration: 00:00:06
> > Log: 181-sbin-ipsecctl.log
> >
> > ike
> > cat /home/src/regress/sbin/ipsecctl/ike56.in | sed -e
> > 's,DIR,/home/src/regress/sbin/ipsecctl,g' | /sbin/ipsecctl -nv -f - |
> > diff -u /home/src/regress/sbin/ipsecctl/ike56.ok /dev/stdin
> > stdin: 1: source/destination address families do not match
> > ipsecctl: Syntax error in config file: ipsec rules not loaded
> > --- /home/src/regress/sbin/ipsecctl/ike56.okFri Sep 2 12:58:24 2016
> > +++ /dev/stdin Tue Nov 21 02:26:19 2023
> > @@ -1,33 +0,0 @@
> > -C set [Phase 1]:127.0.0.1=peer-127.0.0.1 force
> > -C set [peer-127.0.0.1]:Phase=1 force
> > -C set [peer-127.0.0.1]:Address=127.0.0.1 force
> > -C set [peer-127.0.0.1]:Configuration=phase1-peer-127.0.0.1 force
> > -C set [phase1-peer-127.0.0.1]:EXCHANGE_TYPE=ID_PROT force
> > -C add
> > [phase1-peer-127.0.0.1]:Transforms=phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072
> > force
> > -C set
> > [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:AUTHENTICATION_METHOD=RSA_SIG
> > force
> > -C set
> > [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:HASH_ALGORITHM=SHA
> > force
> > -C set
> > [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:ENCRYPTION_ALGORITHM=AES_CBC
> > force
> > -C set
> > [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:KEY_LENGTH=128,128:256
> > force
> > -C set
> > [phase1-trans
Re: CVS: cvs.openbsd.org: src
On 2023-11-20 23:33 +01, Alexander Bluhm wrote:
> On Tue, Nov 14, 2023 at 01:27:33AM -0700, Florian Obser wrote:
>> CVSROOT: /cvs
>> Module name: src
>> Changes by: flor...@cvs.openbsd.org 2023/11/14 01:27:33
>>
>> Modified files:
>> lib/libc/asr : gethostnamadr_async.c
>>
>> Log message:
>> Add break to error out on weird characters in gethostbyname().
>>
>> Missed in previous some time ago; while here remove confusing else.
>>
>> Input & OK eric
>
> This breaks DNS error handling in ifconfig.
>
> # ifconfig foo0 foo:bar
> Segmentation fault (core dumped)
>
> #0 0x05eb2d9dc132 in in_getaddr (s=0x70483ea0f184 "foo:bar", which=1)
> at /usr/src/sbin/ifconfig/ifconfig.c:6413
> 6413memcpy(&sin->sin_addr, hp->h_addr,
> hp->h_length);
>
> bluhm
We need to set the correct ar_ errno, otherwise we return stack garbage.
OK?
diff --git gethostnamadr_async.c gethostnamadr_async.c
index d211679400b..5df767c 100644
--- gethostnamadr_async.c
+++ gethostnamadr_async.c
@@ -205,7 +205,8 @@ gethostnamadr_async_run(struct asr_query *as, struct
asr_result *ar)
}
if (!hnok_lenient(as->as.hostnamadr.name)) {
- ar->ar_gai_errno = EAI_FAIL;
+ ar->ar_h_errno = NETDB_INTERNAL;
+ ar->ar_errno = EINVAL;
async_set_state(as, ASR_STATE_HALT);
break;
}
--
In my defence, I have been left unsupervised.
Re: CVS: cvs.openbsd.org: src
On 2023-11-21 08:04 +01, Anton Lindqvist wrote:
> On Mon, Nov 20, 2023 at 05:15:16AM -0700, Florian Obser wrote:
>> CVSROOT: /cvs
>> Module name: src
>> Changes by: flor...@cvs.openbsd.org 2023/11/20 05:15:16
>>
>> Modified files:
>> lib/libc/asr : asr_private.h asr_utils.c getaddrinfo_async.c
>> gethostnamadr_async.c
>>
>> Log message:
>> localhost is either 127.0.0.1 or ::1, nothing else.
>>
>> RFC 6761, 6.3 Domain Name Reservation Considerations for "localhost.":
>> 3. Name resolution APIs and libraries SHOULD recognize localhost
>> names as special and SHOULD always return the IP loopback address
>> for address queries and negative responses for all other query
>> types. Name resolution APIs SHOULD NOT send queries for
>> localhost names to their configured caching DNS server(s).
>>
>> This makes sure that the getaddrinfo(3) and gethostbyname(3) family of
>> functions always return the loopback address and do not send queries
>> to name servers. This includes "localhost", "localhost." and
>> everything under ".localhost" and ".localhost.".
>>
>> For example, a host underneath the .com.ar zone will per default have
>> a search list of "com.ar.". resolv.conf(5) has a default of "lookup
>> bind file". Both combined will result in lookups for "localhost" to
>> not return 127.0.0.1 because localhost.com.ar is registered in DNS.
>>
>> It has been known for decades that this is a problem, especially for
>> localhost.
>>
>> Problem recently spotted by gonzalo@ and debugged by sthen@
>>
>> Testing sthen, gonzalo
>> Input & OK phessler, eric, millert
>> OK sthen, kn, deraadt
>
> Seeing two new failures. The offending pf rule:
>
> pass in inet6 proto tcp to port 25 divert-to localhost port 8025
>
> pfctl complains about:
>
> stdin:10: divert-to address family mismatch
>
> Changing localhost to ::1 makes it pass again. Is this expected or a
> regression? The ipsecctl failure looks like a symptom of the same
> problem.
We were a bit too enthusiastic short-circuiting "localhost". It has to
fail if AI_NUMERICHOST is set, because "localhost" is not an IP address.
This makes the pfctl and ipsecctl regress tests pass again. (At least
with a non-weird /etc/resolv.conf).
OK?
diff --git getaddrinfo_async.c getaddrinfo_async.c
index f85d541398a..2e5898b6411 100644
--- getaddrinfo_async.c
+++ getaddrinfo_async.c
@@ -115,7 +115,7 @@ getaddrinfo_async_run(struct asr_query *as, struct
asr_result *ar)
char fqdn[MAXDNAME];
const char *str;
struct addrinfo *ai;
- int i, family, r, is_localhost;
+ int i, family, r, is_localhost = 0;
FILE*f;
union {
struct sockaddr sa;
@@ -228,7 +228,8 @@ getaddrinfo_async_run(struct asr_query *as, struct
asr_result *ar)
ar->ar_gai_errno = 0;
- is_localhost = _asr_is_localhost(as->as.ai.hostname);
+ if (!(ai->ai_flags & AI_NUMERICHOST))
+ is_localhost = _asr_is_localhost(as->as.ai.hostname);
/*
* If hostname is NULL, "localhost" or falls within the
* ".localhost." domain, use local address.
>
>> sbin/ipsecctl
> Exit: 1
> Duration: 00:00:06
> Log: 181-sbin-ipsecctl.log
>
> ike
> cat /home/src/regress/sbin/ipsecctl/ike56.in | sed -e
> 's,DIR,/home/src/regress/sbin/ipsecctl,g' | /sbin/ipsecctl -nv -f - |
> diff -u /home/src/regress/sbin/ipsecctl/ike56.ok /dev/stdin
> stdin: 1: source/destination address families do not match
> ipsecctl: Syntax error in config file: ipsec rules not loaded
> --- /home/src/regress/sbin/ipsecctl/ike56.ok Fri Sep 2 12:58:24 2016
> +++ /dev/stdinTue Nov 21 02:26:19 2023
> @@ -1,33 +0,0 @@
> -C set [Phase 1]:127.0.0.1=peer-127.0.0.1 force
> -C set [peer-127.0.0.1]:Phase=1 force
> -C set [peer-127.0.0.1]:Address=127.0.0.1 force
> -C set [peer-127.0.0.1]:Configuration=phase1-peer-127.0.0.1 force
> -C set [phase1-peer-127.0.0.1]:EXCHANGE_TYPE=ID_PROT force
> -C add
> [phase1-peer-127.0.0.1]:Transforms=phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072
> force
> -C set
> [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:AUTHENTICATION_METHOD=RSA_SIG
> force
> -C set
> [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:HASH_ALGORITHM=SHA
> force
> -C set
> [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:ENCRYPTION_ALGORITHM=AES_CBC
> force
> -C set
> [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:KEY_LENGTH=128,128:256
> force
> -C set
> [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:GROUP_DESCRIPTION=MODP_3072
> force
> -C set
> [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:Life=LIFE_MAIN_MODE
> force
> -C set [from-127.0.0.1-to-127.0.0.1]:Phase=2 force
> -C set [from-127.0.0.1-to-127.0.0.1]:ISAKMP-peer=peer-127.0.0.1 force
> -C set
> [
Re: CVS: cvs.openbsd.org: src
On Mon, Nov 20, 2023 at 05:15:16AM -0700, Florian Obser wrote: > CVSROOT: /cvs > Module name: src > Changes by: flor...@cvs.openbsd.org 2023/11/20 05:15:16 > > Modified files: > lib/libc/asr : asr_private.h asr_utils.c getaddrinfo_async.c >gethostnamadr_async.c > > Log message: > localhost is either 127.0.0.1 or ::1, nothing else. > > RFC 6761, 6.3 Domain Name Reservation Considerations for "localhost.": > 3. Name resolution APIs and libraries SHOULD recognize localhost > names as special and SHOULD always return the IP loopback address > for address queries and negative responses for all other query > types. Name resolution APIs SHOULD NOT send queries for > localhost names to their configured caching DNS server(s). > > This makes sure that the getaddrinfo(3) and gethostbyname(3) family of > functions always return the loopback address and do not send queries > to name servers. This includes "localhost", "localhost." and > everything under ".localhost" and ".localhost.". > > For example, a host underneath the .com.ar zone will per default have > a search list of "com.ar.". resolv.conf(5) has a default of "lookup > bind file". Both combined will result in lookups for "localhost" to > not return 127.0.0.1 because localhost.com.ar is registered in DNS. > > It has been known for decades that this is a problem, especially for > localhost. > > Problem recently spotted by gonzalo@ and debugged by sthen@ > > Testing sthen, gonzalo > Input & OK phessler, eric, millert > OK sthen, kn, deraadt Seeing two new failures. The offending pf rule: pass in inet6 proto tcp to port 25 divert-to localhost port 8025 pfctl complains about: stdin:10: divert-to address family mismatch Changing localhost to ::1 makes it pass again. Is this expected or a regression? The ipsecctl failure looks like a symptom of the same problem. > sbin/ipsecctl Exit: 1 Duration: 00:00:06 Log: 181-sbin-ipsecctl.log ike cat /home/src/regress/sbin/ipsecctl/ike56.in | sed -e 's,DIR,/home/src/regress/sbin/ipsecctl,g' | /sbin/ipsecctl -nv -f - | diff -u /home/src/regress/sbin/ipsecctl/ike56.ok /dev/stdin stdin: 1: source/destination address families do not match ipsecctl: Syntax error in config file: ipsec rules not loaded --- /home/src/regress/sbin/ipsecctl/ike56.okFri Sep 2 12:58:24 2016 +++ /dev/stdin Tue Nov 21 02:26:19 2023 @@ -1,33 +0,0 @@ -C set [Phase 1]:127.0.0.1=peer-127.0.0.1 force -C set [peer-127.0.0.1]:Phase=1 force -C set [peer-127.0.0.1]:Address=127.0.0.1 force -C set [peer-127.0.0.1]:Configuration=phase1-peer-127.0.0.1 force -C set [phase1-peer-127.0.0.1]:EXCHANGE_TYPE=ID_PROT force -C add [phase1-peer-127.0.0.1]:Transforms=phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072 force -C set [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:AUTHENTICATION_METHOD=RSA_SIG force -C set [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:HASH_ALGORITHM=SHA force -C set [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:ENCRYPTION_ALGORITHM=AES_CBC force -C set [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:KEY_LENGTH=128,128:256 force -C set [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:GROUP_DESCRIPTION=MODP_3072 force -C set [phase1-transform-peer-127.0.0.1-RSA_SIG-SHA-AES128-MODP_3072]:Life=LIFE_MAIN_MODE force -C set [from-127.0.0.1-to-127.0.0.1]:Phase=2 force -C set [from-127.0.0.1-to-127.0.0.1]:ISAKMP-peer=peer-127.0.0.1 force -C set [from-127.0.0.1-to-127.0.0.1]:Configuration=phase2-from-127.0.0.1-to-127.0.0.1 force -C set [from-127.0.0.1-to-127.0.0.1]:Local-ID=from-127.0.0.1 force -C set [from-127.0.0.1-to-127.0.0.1]:Remote-ID=to-127.0.0.1 force -C set [phase2-from-127.0.0.1-to-127.0.0.1]:EXCHANGE_TYPE=QUICK_MODE force -C set [phase2-from-127.0.0.1-to-127.0.0.1]:Suites=phase2-suite-from-127.0.0.1-to-127.0.0.1 force -C set [phase2-suite-from-127.0.0.1-to-127.0.0.1]:Protocols=phase2-protocol-from-127.0.0.1-to-127.0.0.1 force -C set [phase2-protocol-from-127.0.0.1-to-127.0.0.1]:PROTOCOL_ID=IPSEC_ESP force -C set [phase2-protocol-from-127.0.0.1-to-127.0.0.1]:Transforms=phase2-transform-from-127.0.0.1-to-127.0.0.1-AES128-SHA2_256-MODP_3072-TUNNEL force -C set [phase2-transform-from-127.0.0.1-to-127.0.0.1-AES128-SHA2_256-MODP_3072-TUNNEL]:TRANSFORM_ID=AES force -C set [phase2-transform-from-127.0.0.1-to-127.0.0.1-AES128-SHA2_256-MODP_3072-TUNNEL]:KEY_LENGTH=128,128:256 force -C set [phase2-transform-from-127.0.0.1-to-127.0.0.1-AES128-SHA2_256-MODP_3072-TUNNEL]:ENCAPSULATION_MODE=TUNNEL force -C set [phase2-transform-from-127.0.0.1-to-127.0.0.1-AES128-SHA2_256-MODP_3072-TUNNEL]:AUTHENTICATION_ALGORITHM=HMAC_SHA2_256 force -C set [phase2-transform-from-127.0.0.1-to-127.0.0.1-AES128-SHA2_256-MODP_3072-TUNNEL]:GROUP_DESCRIPTION=MODP_3072 force -C set [phase2-transform-from-127.0.0.1-to-127.0.0.1-AES128-SHA2_256-MODP_3072-TUNNEL]:Life=LIFE_QUICK_MOD
Re: CVS: cvs.openbsd.org: src
On Tue, Nov 14, 2023 at 01:27:33AM -0700, Florian Obser wrote: > CVSROOT: /cvs > Module name: src > Changes by: flor...@cvs.openbsd.org 2023/11/14 01:27:33 > > Modified files: > lib/libc/asr : gethostnamadr_async.c > > Log message: > Add break to error out on weird characters in gethostbyname(). > > Missed in previous some time ago; while here remove confusing else. > > Input & OK eric This breaks DNS error handling in ifconfig. # ifconfig foo0 foo:bar Segmentation fault (core dumped) #0 0x05eb2d9dc132 in in_getaddr (s=0x70483ea0f184 "foo:bar", which=1) at /usr/src/sbin/ifconfig/ifconfig.c:6413 6413memcpy(&sin->sin_addr, hp->h_addr, hp->h_length); bluhm
Re: CVS: cvs.openbsd.org: src
On Mon, Oct 23, 2023 at 01:12:09PM -0400, Daniel Jakots wrote: > On Mon, 23 Oct 2023 02:38:14 -0600 (MDT), Marc Espie > wrote: > > > CVSROOT:/cvs > > Module name:src > > Changes by: es...@cvs.openbsd.org 2023/10/23 02:38:14 > > > > Modified files: > > usr.sbin/pkg_add/OpenBSD: AddCreateDelete.pm > > > > Log message: > > split on spaces as well, to take advantage of += > > > > I just updated a machine and now pkg_add fails: > > # pkg_add -u > syntax error at /usr/libdata/perl5/OpenBSD/Subst.pm line 54, near "" $v")" > Compilation failed in require at /usr/libdata/perl5/OpenBSD/State.pm line 73. > BEGIN failed--compilation aborted at /usr/libdata/perl5/OpenBSD/State.pm line > 73. Yeah, not sure how I managed to fuck that one. Fixed for real
Re: CVS: cvs.openbsd.org: src
On 23/10/2023 19:12, Daniel Jakots wrote: On Mon, 23 Oct 2023 02:38:14 -0600 (MDT), Marc Espie wrote: CVSROOT:/cvs Module name:src Changes by: es...@cvs.openbsd.org 2023/10/23 02:38:14 Modified files: usr.sbin/pkg_add/OpenBSD: AddCreateDelete.pm Log message: split on spaces as well, to take advantage of += I just updated a machine and now pkg_add fails: # pkg_add -u syntax error at /usr/libdata/perl5/OpenBSD/Subst.pm line 54, near "" $v")" Compilation failed in require at /usr/libdata/perl5/OpenBSD/State.pm line 73. BEGIN failed--compilation aborted at /usr/libdata/perl5/OpenBSD/State.pm line 73. Compilation failed in require at /usr/libdata/perl5/OpenBSD/AddCreateDelete.pm line 26. BEGIN failed--compilation aborted at /usr/libdata/perl5/OpenBSD/AddCreateDelete.pm line 26. Compilation failed in require at /usr/libdata/perl5/OpenBSD/AddDelete.pm line 60. BEGIN failed--compilation aborted at /usr/libdata/perl5/OpenBSD/AddDelete.pm line 60. Compilation failed in require at /usr/libdata/perl5/OpenBSD/PkgAdd.pm line 22. BEGIN failed--compilation aborted at /usr/libdata/perl5/OpenBSD/PkgAdd.pm line 22. Compilation failed in require at (eval 1) line 1. could it be related? Cheers, Daniel I don't think so, if I revert the following commit pkg_add works again on my machine CVSROOT:/cvs Module name:src Changes by: es...@cvs.openbsd.org 2023/10/23 02:37:45 Modified files: usr.sbin/pkg_add/OpenBSD: Subst.pm Log message: add some limited capability to -DVAR+=value to be used with REGRESSION_TESTING, where it's somewhat inconvenient to know the full list in advance.
Re: CVS: cvs.openbsd.org: src
On Mon, 23 Oct 2023 02:38:14 -0600 (MDT), Marc Espie wrote: > CVSROOT: /cvs > Module name: src > Changes by: es...@cvs.openbsd.org 2023/10/23 02:38:14 > > Modified files: > usr.sbin/pkg_add/OpenBSD: AddCreateDelete.pm > > Log message: > split on spaces as well, to take advantage of += > I just updated a machine and now pkg_add fails: # pkg_add -u syntax error at /usr/libdata/perl5/OpenBSD/Subst.pm line 54, near "" $v")" Compilation failed in require at /usr/libdata/perl5/OpenBSD/State.pm line 73. BEGIN failed--compilation aborted at /usr/libdata/perl5/OpenBSD/State.pm line 73. Compilation failed in require at /usr/libdata/perl5/OpenBSD/AddCreateDelete.pm line 26. BEGIN failed--compilation aborted at /usr/libdata/perl5/OpenBSD/AddCreateDelete.pm line 26. Compilation failed in require at /usr/libdata/perl5/OpenBSD/AddDelete.pm line 60. BEGIN failed--compilation aborted at /usr/libdata/perl5/OpenBSD/AddDelete.pm line 60. Compilation failed in require at /usr/libdata/perl5/OpenBSD/PkgAdd.pm line 22. BEGIN failed--compilation aborted at /usr/libdata/perl5/OpenBSD/PkgAdd.pm line 22. Compilation failed in require at (eval 1) line 1. could it be related? Cheers, Daniel
Re: CVS: cvs.openbsd.org: src
On 2023/10/03 04:22, Stuart Henderson wrote: > CVSROOT: /cvs > Module name: src > Changes by: st...@cvs.openbsd.org 2023/10/03 04:22:10 > > Modified files: > sys/net: if_pfsync.c > > Log message: > Reinstate setting rtableid based on rdomain for pfsync, > lost during the rewrite, reported by Mark Patruck. > > ok phessler claudio sashan deraadt > and dlg
Re: CVS: cvs.openbsd.org: src
On Thu, 21 Sep 2023 11:19:06 -0600, Todd C. Miller wrote: > CVSROOT: /cvs > Module name: src > Changes by: mill...@cvs.openbsd.org 2023/09/21 11:19:06 > > Modified files: > usr.bin/awk: b.c > > Log message: > Fix a potential out-of-bounds read caused by the big-endian fix. > > We must store a UTF-32 empty string, not UTF-8 empty string, for > an empty CCL. Found running the awk test suite with address sanitizer. Actually, this bug is also present in upstream awk, without the big-endian fix. - todd
Re: CVS: cvs.openbsd.org: src
On 2023/09/16 01:59:44 -0600, Omar Polo wrote: > CVSROOT: /cvs > Module name: src > Changes by: o...@cvs.openbsd.org2023/09/16 01:59:44 > > Modified files: > share/man/man5 : bsd.port.mk.5 > > Log message: > document CHECK_LIB_DEPENDS_ARGS sigh, and this improved and okay'd espie@ too. sorry...
Re: CVS: cvs.openbsd.org: src
Hello, I was about to start looking into it. however there was another mail in my inbox where I learned naddy@ has backed out the commit. bluhm@ and I agree with him. the change attempts to fix awkward corner case doing more harm than good. thanks and regards sashan pá 8. 9. 2023 v 12:59 odesílatel Anton Lindqvist napsal: > > On Thu, Sep 07, 2023 at 03:59:43AM -0600, Alexandr Nedvedicky wrote: > > CVSROOT: /cvs > > Module name: src > > Changes by: sas...@cvs.openbsd.org 2023/09/07 03:59:43 > > > > Modified files: > > sys/net: pf.c > > > > Log message: > > pf(4) ignores 'keep state' and 'nat-to' actions for unsolicited > > icmp error responses. Fix tightens rule matching logic so icmp > > error responses no longer match 'keep state' rule. In typical > > scenarios icmp errors (if solicited) should match existing state. > > The change is going to bite firewalls which deal with asymmetric > > routes. In those cases the 'keep state' action should be relaxed > > to sloppy or new 'no state' rule to explicitly match icmp > > errors should be added. > > > > The issue has been reported by Peter J. Philip (pjp _at_ delphinusdns.org). > > > > Discussed with bluhm@ and florian@ > > > > OK bluhm@ > > Couple of new failures. Reverting this commit makes the problem go away. > > https://regress.basename.se/amd64/2023-09-08.1/296-sys-net-pair.log > https://regress.basename.se/amd64/2023-09-08.1/310-sys-net-vxlan.log > https://regress.basename.se/amd64/2023-09-08.1/397-usr.sbin-bgpd.log > https://regress.basename.se/amd64/2023-09-08.1/405-usr.sbin-ospf6d.log
Re: CVS: cvs.openbsd.org: src
On Thu, Sep 07, 2023 at 03:59:43AM -0600, Alexandr Nedvedicky wrote: > CVSROOT: /cvs > Module name: src > Changes by: sas...@cvs.openbsd.org 2023/09/07 03:59:43 > > Modified files: > sys/net: pf.c > > Log message: > pf(4) ignores 'keep state' and 'nat-to' actions for unsolicited > icmp error responses. Fix tightens rule matching logic so icmp > error responses no longer match 'keep state' rule. In typical > scenarios icmp errors (if solicited) should match existing state. > The change is going to bite firewalls which deal with asymmetric > routes. In those cases the 'keep state' action should be relaxed > to sloppy or new 'no state' rule to explicitly match icmp > errors should be added. > > The issue has been reported by Peter J. Philip (pjp _at_ delphinusdns.org). > > Discussed with bluhm@ and florian@ > > OK bluhm@ Couple of new failures. Reverting this commit makes the problem go away. https://regress.basename.se/amd64/2023-09-08.1/296-sys-net-pair.log https://regress.basename.se/amd64/2023-09-08.1/310-sys-net-vxlan.log https://regress.basename.se/amd64/2023-09-08.1/397-usr.sbin-bgpd.log https://regress.basename.se/amd64/2023-09-08.1/405-usr.sbin-ospf6d.log
