Re: Unwind + NSD usage question

2021-09-28 Thread Otto Moerbeek
On Mon, Sep 27, 2021 at 08:50:06PM -0400, abyx...@mnetic.ch wrote: > Hello, trying to set up unwind with nsd on the same machine serving a > internal domain (home.arpa) with all my machines being part of that domain, > eg router.home.arpa. If I point dig at my nsd instance (dig @127.0.0.1 -p >

Re: libedit: stop ignoring SIGINT

2021-08-09 Thread Otto Moerbeek
On Mon, Aug 09, 2021 at 07:20:31AM -0600, Theo de Raadt wrote: > Ingo Schwarze wrote: > > > as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C. > > Fixing that without longjmp(3) requires making editline(3) better > > behaved. > > If a library interface encourages use

Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)

2021-07-31 Thread Otto Moerbeek
On Fri, Jul 30, 2021 at 09:54:27AM -0600, Gavin Howard wrote: > Whoops; I thought Theo would make the decision, and his last email made > me think he might have. > > I am happy to help as much as I can to make the process easy for you. > > In the meantime, I think I will release 5.0.0 when it's

Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)

2021-07-30 Thread Otto Moerbeek
On Thu, Jul 29, 2021 at 10:31:34PM -0600, Gavin Howard wrote: > Hello, > > At this point, because of the lack of reply, I am going to assume that > my proposal is rejected. While I am sad, I understand. > > Thank you for taking the time to consider my proposal. > > Gavin Howard > I just did

Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)

2021-06-17 Thread Otto Moerbeek
On Thu, Jun 17, 2021 at 10:01:02AM -0600, Gavin Howard wrote: > Otto, > > > I think it is interesting. As for the incompatibilites, my memory says > > I followed the original dc and bc when deciding on those (GNU chose to > > differs in these cases). Bit it has been 18 years since I wrote the >

Re: [CAN IGNORE] Proposal for new bc(1) and dc(1)

2021-06-17 Thread Otto Moerbeek
On Wed, Jun 16, 2021 at 11:40:08PM -0600, Gavin Howard wrote: > Hello, > > My name is Gavin Howard. I have developed a new bc(1) and dc(1) > implementation. [0] > > I propose replacing the current implementations with mine. > > Advantages: > > * Performance. [1] > * Extensions for ease of

Re: Ryzen 5800X hw.setperf vs hw.cpuspeed

2021-06-01 Thread Otto Moerbeek
> [1] https://www.gigabyte.com/Motherboard/AORUS-Gaming > [2] https://www.gigabyte.com/Motherboard/B550-AORUS-ELITE-rev-10/sp#sp > > On Fri, Nov 20, 2020 at 9:28 AM Otto Moerbeek wrote: > > > > Hi, > > > > I got a new Ryzen machine, dmesg below. What I'm observ

Re: pthread_once fix memory leak

2021-05-02 Thread Otto Moerbeek
On Sun, May 02, 2021 at 02:07:21PM +0200, Mark Kettenis wrote: > > From: Martijn van Duren > > Date: Sun, 02 May 2021 13:28:10 +0200 > > > > Found this while tracing a memory leak in filter-dkimsign, thanks to > > libcrypto. The mutex in pthread_once_t is never destroyed, so the > > memory

Re: malloc vs emacs

2021-04-28 Thread Otto Moerbeek
On Sun, Apr 25, 2021 at 06:41:09PM +0200, Mark Kettenis wrote: > > Date: Sun, 25 Apr 2021 17:53:31 +0200 > > From: Otto Moerbeek > > > > Hi, > > > > A local test and jca@ confirm the special casing isn't needed anymore. > > > > Two things:

malloc vs emacs

2021-04-25 Thread Otto Moerbeek
Hi, A local test and jca@ confirm the special casing isn't needed anymore. Two things: - This could do with a ports bulk build to find other offenders - Would this require a libc bump? -Otto Index: hidden/stdlib.h ===

Re: small malloc diff

2021-04-08 Thread Otto Moerbeek
On Fri, Apr 09, 2021 at 07:39:05AM +0200, Theo Buehler wrote: > On Fri, Apr 09, 2021 at 07:36:35AM +0200, Otto Moerbeek wrote: > > On Thu, Apr 01, 2021 at 11:23:58AM +0200, Otto Moerbeek wrote: > > > > > Hi, > > > > > > here's a small malloc diff

Re: small malloc diff

2021-04-08 Thread Otto Moerbeek
On Thu, Apr 01, 2021 at 11:23:58AM +0200, Otto Moerbeek wrote: > Hi, > > here's a small malloc diff. Most important part is an extra internal > consistency check. I have been running this for a few week already, ping? > > -Otto > >

small malloc diff

2021-04-01 Thread Otto Moerbeek
Hi, here's a small malloc diff. Most important part is an extra internal consistency check. I have been running this for a few week already, -Otto Index: stdlib/malloc.3 === RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v

Re: vmm crash on 6.9-beta

2021-03-22 Thread Otto Moerbeek
On Mon, Mar 22, 2021 at 03:20:37PM +0100, Mischa wrote: > > > > On 22 Mar 2021, at 15:18, Otto Moerbeek wrote: > > > > On Mon, Mar 22, 2021 at 03:06:40PM +0100, Mischa wrote: > > > >>> On 22 Mar 2021, at 15:05, Dave Voutila wrote: > >>

Re: vmm crash on 6.9-beta

2021-03-22 Thread Otto Moerbeek
On Mon, Mar 22, 2021 at 03:06:40PM +0100, Mischa wrote: > > On 22 Mar 2021, at 15:05, Dave Voutila wrote: > > Otto Moerbeek writes: > >> On Mon, Mar 22, 2021 at 09:51:19AM -0400, Dave Voutila wrote: > >>> Otto Moerbeek writes: > >>>> On Mon

Re: vmm crash on 6.9-beta

2021-03-22 Thread Otto Moerbeek
On Mon, Mar 22, 2021 at 01:59:17PM +, Stuart Henderson wrote: > > > I'm more familiar with the vmd(8) codebase than any ffs stuff, but I > > > don't think the issue is the base image being r/w. > > > > AFAIKS, the issue is that if you start a vm modifying the base because it > > uses it as a

Re: vmm crash on 6.9-beta

2021-03-22 Thread Otto Moerbeek
On Mon, Mar 22, 2021 at 09:51:19AM -0400, Dave Voutila wrote: > > Otto Moerbeek writes: > > > On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote: > > > >> > >> > >> > On 22 Mar 2021, at 13:43, Stuart Henderson wrote: > >> >

Re: vmm crash on 6.9-beta

2021-03-22 Thread Otto Moerbeek
On Mon, Mar 22, 2021 at 01:47:18PM +0100, Mischa wrote: > > > > On 22 Mar 2021, at 13:43, Stuart Henderson wrote: > > > >>> Created a fresh install qcow2 image and derived 35 new VMs from it. > >>> Then I started all the VMs in four cycles, 10 VMs per cycle and waiting > >>> 240 seconds

Re: vmm crash on 6.9-beta

2021-03-22 Thread Otto Moerbeek
On Mon, Mar 22, 2021 at 11:34:25AM +0100, Mischa wrote: > > On 21 Mar 2021, at 02:31, Theo de Raadt wrote: > > Otto Moerbeek wrote: > >> On Fri, Mar 19, 2021 at 04:15:31PM +, Stuart Henderson wrote: > >> > >>> On 2021/03/19 17:05, Jan Klemkow wrote

Re: slaacd(8): pltime 0 and temporary addresses

2021-03-21 Thread Otto Moerbeek
On Sun, Mar 21, 2021 at 02:38:42PM +0100, Florian Obser wrote: > > Don't warn that we can't form a temporary address when a router > deprecates a prefix by sending a pltime of 0, this is normal. > Continue warning when the pltime is smaller than 5 as this is almost > certainly a configuration

Re: vmm crash on 6.9-beta

2021-03-20 Thread Otto Moerbeek
On Fri, Mar 19, 2021 at 04:15:31PM +, Stuart Henderson wrote: > On 2021/03/19 17:05, Jan Klemkow wrote: > > Hi, > > > > I had the same issue a few days ago a server hardware of mine. I just > > ran 'cvs up'. So, it looks like a generic bug in FFS and not related to > > vmm. > > This panic

Re: vmm crash on 6.9-beta

2021-03-13 Thread Otto Moerbeek
On Sat, Mar 13, 2021 at 12:08:52AM -0800, Mike Larkin wrote: > On Wed, Mar 10, 2021 at 08:30:32PM +0100, Mischa wrote: > > On 10 Mar at 18:59, Mike Larkin wrote: > > > On Wed, Mar 10, 2021 at 03:08:21PM +0100, Mischa wrote: > > > > Hi All, > > > > > > > > Currently I am running 6.9-beta on one

Re: malloc cache changes

2021-03-09 Thread Otto Moerbeek
On Tue, Mar 09, 2021 at 09:12:03AM +0100, Otto Moerbeek wrote: > Hi, > > I just committed a malloc change that is interesting. It has been in > snaps already for a while. > > It changes the malloc cache to be a little more friendly to the > kernel, mallocs tendency to sp

malloc cache changes

2021-03-09 Thread Otto Moerbeek
Hi, I just committed a malloc change that is interesting. It has been in snaps already for a while. It changes the malloc cache to be a little more friendly to the kernel, mallocs tendency to split large allocations into page-sized ones was giving the kernel a hard time in some cases. By

Re: occasional SSIGSEGV on C++ exception handling

2021-02-22 Thread Otto Moerbeek
On Tue, Feb 23, 2021 at 06:23:22PM +1100, Jonathan Gray wrote: > On Tue, Feb 23, 2021 at 08:10:54AM +0100, Otto Moerbeek wrote: > > On Mon, Feb 22, 2021 at 08:58:07PM -, Miod Vallat wrote: > > > > > > > > > No problem, real-life often takes precedence. &g

Re: occasional SSIGSEGV on C++ exception handling

2021-02-22 Thread Otto Moerbeek
On Mon, Feb 22, 2021 at 08:58:07PM -, Miod Vallat wrote: > > > No problem, real-life often takes precedence. > > No way! operator(7) would need an update! > What do we do when we see a bug? We fix it! What if it is not fixable? We document it! -Otto Index: operator.7

Re: occasional SSIGSEGV on C++ exception handling

2021-02-22 Thread Otto Moerbeek
On Mon, Feb 22, 2021 at 11:09:41AM +0200, Paul Irofti wrote: > > - investigate the commit you mention above. Sadly I cannot > >remember the original case that prompted for the caching code to > > be > >added. > > Sorry I could not reply earlier. No problem,

Re: occasional SSIGSEGV on C++ exception handling

2021-02-20 Thread Otto Moerbeek
On Sat, Feb 20, 2021 at 06:30:23PM +0100, Mark Kettenis wrote: > > Date: Sat, 20 Feb 2021 18:23:26 +0100 > > From: Otto Moerbeek > > Cc: tech@openbsd.org, piro...@openbsd.org > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > >

Re: occasional SSIGSEGV on C++ exception handling

2021-02-20 Thread Otto Moerbeek
On Fri, Feb 19, 2021 at 05:29:31PM +0100, Mark Kettenis wrote: > > Date: Fri, 19 Feb 2021 16:43:10 +0100 > > From: Otto Moerbeek > > > > On Fri, Feb 19, 2021 at 01:06:43PM +0100, Otto Moerbeek wrote: > > > > > On Fri, Feb 19, 2021 at 12:45:58PM +0100, Mar

Re: occasional SSIGSEGV on C++ exception handling

2021-02-19 Thread Otto Moerbeek
On Fri, Feb 19, 2021 at 01:06:43PM +0100, Otto Moerbeek wrote: > On Fri, Feb 19, 2021 at 12:45:58PM +0100, Mark Kettenis wrote: > > > > Date: Fri, 19 Feb 2021 10:57:30 +0100 > > > From: Otto Moerbeek > > > > > > Hi, > > > > > &

Re: occasional SSIGSEGV on C++ exception handling

2021-02-19 Thread Otto Moerbeek
On Fri, Feb 19, 2021 at 12:45:58PM +0100, Mark Kettenis wrote: > > Date: Fri, 19 Feb 2021 10:57:30 +0100 > > From: Otto Moerbeek > > > > Hi, > > > > working on PowerDNS Recursor, once in a while I'm seeing: > > > > #0 0x09fd67

occasional SSIGSEGV on C++ exception handling

2021-02-19 Thread Otto Moerbeek
Hi, working on PowerDNS Recursor, once in a while I'm seeing: #0 0x09fd67ef09dc in libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR (this=, head=0x9fd67efc8e8 , elm=0x9fca04be900) at /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243 243

Re: if calloc() needs nmemb and size, why doesn't freezero()?

2021-02-18 Thread Otto Moerbeek
On Thu, Feb 18, 2021 at 03:24:36PM -0600, Luke Small wrote: > However, calloc(ptr, nmemb, size) may have been called using smaller int > variable types which would overflow when multiplied. Where if the variables > storing the values passed to nmemb and size are less than or especially > equal to

Re: malloc junking tweaks

2021-02-18 Thread Otto Moerbeek
On Fri, Feb 12, 2021 at 02:48:34PM +0100, Otto Moerbeek wrote: > On Fri, Feb 12, 2021 at 02:18:08PM +0100, Otto Moerbeek wrote: > > > Hi, > > > > Curently, junking is done like this: > > > > - for small chunk, the whole chunk junked on free > > > &

Re: if calloc() needs nmemb and size, why doesn't freezero()?

2021-02-18 Thread Otto Moerbeek
On Wed, Feb 17, 2021 at 11:05:49AM -0700, Theo de Raadt wrote: > Luke Small wrote: > > > I guess I always thought there'd be some more substantial overflow > > mitigation. > > You have to free with the exact same size as allocation. Small correction: the size may be smaller than the

Re: malloc junking tweaks

2021-02-12 Thread Otto Moerbeek
On Fri, Feb 12, 2021 at 02:18:08PM +0100, Otto Moerbeek wrote: > Hi, > > Curently, junking is done like this: > > - for small chunk, the whole chunk junked on free > > - for pages sized and larger, the first half a page is filled > > - after a delayed free, the fir

malloc junking tweaks

2021-02-12 Thread Otto Moerbeek
Hi, Curently, junking is done like this: - for small chunk, the whole chunk junked on free - for pages sized and larger, the first half a page is filled - after a delayed free, the first 32 bytes of small chunks are validated to not be overwritten - page sized and larger allocations are not

Re: execve -1 errno 12 Cannot allocate memory

2021-02-01 Thread Otto Moerbeek
On Mon, Feb 01, 2021 at 10:24:31PM -0500, Philippe Meunier wrote: > Anyone? Fixing a particluar issue is fine, but more important is an assessment it does not break other things. In particular, does this limit the VM for data available to any program (which is already quite limited on i386)?

Re: [PATCH v3 (resend)] tee: Add -q, --quiet, --silent option to not write to stdout

2021-01-24 Thread Otto Moerbeek
On Sun, Jan 24, 2021 at 01:01:45PM -0700, Alex Henrie wrote: > On Sun, Jan 24, 2021 at 10:51 AM Otto Moerbeek wrote: > > > > Please stop pushing your diff to this list. So far nobody showed any > > interest. > > I am definitely interested. Bernhard Voelker seemed to

Re: unwind: silence "udp connect failed" errors

2021-01-24 Thread Otto Moerbeek
On Sun, Jan 24, 2021 at 07:24:07PM +0100, Florian Obser wrote: > On Sun, Jan 24, 2021 at 01:06:31PM +0100, Klemens Nanni wrote: > > On Sun, Jan 24, 2021 at 12:52:50PM +0100, Theo Buehler wrote: > > > Probably better to sync first with the corresponding unbound commit > > >

Re: [PATCH v3 (resend)] tee: Add -q, --quiet, --silent option to not write to stdout

2021-01-24 Thread Otto Moerbeek
On Sun, Jan 24, 2021 at 01:18:46PM +0100, Alejandro Colomar wrote: > This is useful for using tee to just write to a file, > at the end of a pipeline, > without having to redirect to /dev/null > > Example: > > echo 'foo' | sudo tee -q /etc/foo; > > is equivalent to the old (and ugly) You keep

Re: [PATCH] tee: Add -q, --quiet, --silent option to not write to stdout

2021-01-23 Thread Otto Moerbeek
On Sat, Jan 23, 2021 at 03:28:01PM +, Stuart Henderson wrote: > [cc's trimmed] > > On 2021/01/23 15:53, Alejandro Colomar wrote: > > This is useful for using tee to just write to a file, > > at the end of a pipeline, > > without having to redirect to /dev/null > > > > Example: > > > > echo

cmp -s bugfix

2021-01-08 Thread Otto Moerbeek
As reported on misc@ https://marc.info/?l=openbsd-misc=161016188503894=2 -Otto Index: regular.c === RCS file: /cvs/src/usr.bin/cmp/regular.c,v retrieving revision 1.12 diff -u -p -r1.12 regular.c --- regular.c 6 Feb 2015

Re: use getnameinfo in bgpd to print addresses

2021-01-04 Thread Otto Moerbeek
On Mon, Jan 04, 2021 at 05:50:53PM +0100, Otto Moerbeek wrote: > tOn Mon, Jan 04, 2021 at 01:42:48PM +0100, Theo Buehler wrote: > > > > > + return log_sockaddr(addr2sa(addr, 0, ), len); > > > > > > Perhaps I haven't yet had enough coffee thi

Re: Thread local data setup and destruct

2021-01-04 Thread Otto Moerbeek
On Mon, Jan 04, 2021 at 06:03:46PM +0100, Mark Kettenis wrote: > > Date: Sun, 3 Jan 2021 13:47:45 +0100 > > From: Otto Moerbeek > > > > On Thu, Dec 31, 2020 at 05:54:06PM +0100, Alexander Bluhm wrote: > > > > > On Tue, Dec 29, 2020 at 04:07:19PM +0100, O

Re: use getnameinfo in bgpd to print addresses

2021-01-04 Thread Otto Moerbeek
tOn Mon, Jan 04, 2021 at 01:42:48PM +0100, Theo Buehler wrote: > > > + return log_sockaddr(addr2sa(addr, 0, ), len); > > > > Perhaps I haven't yet had enough coffee this year, but I'm unsure > > whether it is actually guaranteed that addr2sa() is called before the > > second len in this

Re: Thread local data setup and destruct

2021-01-03 Thread Otto Moerbeek
On Thu, Dec 31, 2020 at 05:54:06PM +0100, Alexander Bluhm wrote: > On Tue, Dec 29, 2020 at 04:07:19PM +0100, Otto Moerbeek wrote: > > This workds better, checking the flags does not work if the thread is > > already on the road to desctruction. > > This diff survived a full

Re: drm(4) memory allocation diff

2021-01-01 Thread Otto Moerbeek
On Thu, Dec 31, 2020 at 10:09:36PM +0100, Mark Kettenis wrote: > The diff below changes the emulated Linux memory allocation functions > a bit such that they only use malloc(9) for allocations smaller than a > page. This reduces pressure on the "interrupt safe" map and hopefully > will avoid the

Re: Thread local data setup and destruct

2020-12-29 Thread Otto Moerbeek
On Tue, Dec 29, 2020 at 01:42:57PM +0100, Otto Moerbeek wrote: > On Tue, Dec 29, 2020 at 12:46:54PM +0100, Mark Kettenis wrote: > > > > Date: Tue, 29 Dec 2020 12:21:25 +0100 > > > From: Otto Moerbeek > > > > > > Hi, > > > &g

Re: Thread local data setup and destruct

2020-12-29 Thread Otto Moerbeek
On Tue, Dec 29, 2020 at 12:46:54PM +0100, Mark Kettenis wrote: > > Date: Tue, 29 Dec 2020 12:21:25 +0100 > > From: Otto Moerbeek > > > > Hi, > > > > this is a continuation from the threads on bugs@ > > > > This version makes it explicit t

Thread local data setup and destruct

2020-12-29 Thread Otto Moerbeek
Hi, this is a continuation from the threads on bugs@ This version makes it explicit to *only* setup "TLS" (which actually is just a pointer to static data) with the data provided if we're running single threaded (ie.. no -pthread or -pthread but no pthread function that triggers multi-threaded

Re: Wake on LAN support for rge(4)

2020-12-23 Thread Otto Moerbeek
On Wed, Dec 23, 2020 at 12:35:46PM +0800, Kevin Lo wrote: > Hi, > > This diff implements WoL support in rge(4). I can wakeup the machine with WoL > after suspending it through `zzz` or powering off it through `halt -p`. Thanks! This works as expected in my testing. -Otto > > Index:

Re: kdump: show scope for v6 addresses if set

2020-12-20 Thread Otto Moerbeek
On Sun, Dec 20, 2020 at 02:34:09PM +0100, Claudio Jeker wrote: > On Sun, Dec 20, 2020 at 01:39:57PM +0100, Otto Moerbeek wrote: > > Hi, > > > > scope is there, just not shown. While there, use proper constants for > > two sizes. > > > >

kdump: show scope for v6 addresses if set

2020-12-20 Thread Otto Moerbeek
Hi, scope is there, just not shown. While there, use proper constants for two sizes. -Otto Index: ktrstruct.c === RCS file: /cvs/src/usr.bin/kdump/ktrstruct.c,v retrieving revision 1.28 diff -u -p -r1.28 ktrstruct.c ---

Re: dig vs ipv6 (scoped) addresses

2020-12-20 Thread Otto Moerbeek
On Sun, Dec 20, 2020 at 10:48:01AM +0100, Florian Obser wrote: > On Thu, Dec 17, 2020 at 12:15:16PM +0100, Otto Moerbeek wrote: > > Hi, > > > > > as noted on misc dig does not like to talk to local link addresses. > > This fixes that case. While investig

dig vs ipv6 (scoped) addresses

2020-12-17 Thread Otto Moerbeek
Hi, as noted on misc dig does not like to talk to local link addresses. This fixes that case. While investigating I also found another bug: selecting v6 or v4 addresses only from resolv.conf via the -4 or -6 command line argument does not work as expected. This fixes both. I did not test binding

Re: syspatch exit state

2020-12-06 Thread Otto Moerbeek
On Sun, Dec 06, 2020 at 03:31:19PM +, SW wrote: > On 06/12/2020 14:32, Otto Moerbeek wrote: > > On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote: > > > >> Hi, > >> I've been looking to have syspatch give me a quick indication of whether > >> a r

Re: syspatch exit state

2020-12-06 Thread Otto Moerbeek
On Sun, Dec 06, 2020 at 02:19:05PM +, SW wrote: > Hi, > I've been looking to have syspatch give me a quick indication of whether > a reboot is likely to be required. As a quick and dirty check, I've just > been treating "Were patches applied?" as the indicator. > > The following diff will

Re: clean /dev from /etc/daily ?

2020-11-23 Thread Otto Moerbeek
tOn Mon, Nov 23, 2020 at 01:53:01PM +0100, Solene Rapenne wrote: > A common mistake when using dd is to create a file in /dev which > fills up the space of / and may stay silent until / gets filled up > by something else that will fail. > > Would it be OK to add this in /etc/daily? > > find

Ryzen 5800X hw.setperf vs hw.cpuspeed

2020-11-20 Thread Otto Moerbeek
Hi, I got a new Ryzen machine, dmesg below. What I'm observing might be a issue with hw.setperf. On startsup it shows: hw.cpuspeed=3800 hw.setperf=100 If I lower hw.setperf to zero, the new state is reflect immediately in hw.cpuspeed: hw.cpuspeed=2200

Re: diff: tcp ack improvement

2020-11-05 Thread Otto Moerbeek
On Fri, Nov 06, 2020 at 01:10:52AM +0100, Jan Klemkow wrote: > Hi, > > bluhm and I make some network performance measurements and kernel > profiling. > > Setup:Linux (iperf) -10gbit-> OpenBSD (relayd) -10gbit-> Linux (iperf) > > We figured out, that the kernel uses a huge amount of

Re: dig(1): Extended DNS Error (RFC 8914)

2020-10-30 Thread Otto Moerbeek
On Fri, Oct 30, 2020 at 03:04:03PM +0100, Florian Obser wrote: Love it, -Otto > $ obj/dig @1.1.1.1 dnssec-failed.org > > ; <<>> dig 9.10.8-P1 <<>> @1.1.1.1 dnssec-failed.org > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status:

tree.h: returning void, legal but weird

2020-10-10 Thread Otto Moerbeek
OK? -Otto Index: tree.h === RCS file: /cvs/src/sys/sys/tree.h,v retrieving revision 1.29 diff -u -p -r1.29 tree.h --- tree.h 30 Jul 2017 19:27:20 - 1.29 +++ tree.h 10 Oct 2020 16:36:15 - @@ -910,25

Re: random canary bytes for malloc

2020-10-04 Thread Otto Moerbeek
On Tue, Sep 29, 2020 at 08:17:54AM +0200, Otto Moerbeek wrote: > Hi, > > until now, canary bytes (used by the C olption) were the same as the > bytes used to junk (0xfd). This means that certain overwrites are not > detected, like setting the high bit. > > This make

dump: better handling of large filesystems

2020-09-29 Thread Otto Moerbeek
Hi, this fixes an overwrite of spcl.c_addr. Taken form FreeBSD. See https://marc.info/?l=openbsd-misc=160018252418088=2 -Otto Index: tape.c === RCS file: /cvs/src/sbin/dump/tape.c,v retrieving revision 1.45 diff -u -p

random canary bytes for malloc

2020-09-29 Thread Otto Moerbeek
Hi, until now, canary bytes (used by the C olption) were the same as the bytes used to junk (0xfd). This means that certain overwrites are not detected, like setting the high bit. This makes the byte value used to write canaries random. I do not want to complicate the code to handle all

Re: btrace: add boolean AND and OR operators

2020-09-14 Thread Otto Moerbeek
On Mon, Sep 14, 2020 at 03:28:17PM +0200, Jasper Lievisse Adriaanse wrote: > Hi, > > This diff adds support for the '&' and '|' operators, along with > a new testcase. > > OK? The precedence looks funny I'd guess you want %left '|' %left '&' %left '+' '-' %left '/' '*' To avoid suprises.

Re: asn1/a_bitstring.c: zeroing after recallocarray

2020-09-02 Thread Otto Moerbeek
On Thu, Sep 03, 2020 at 07:03:14AM +0200, Theo Buehler wrote: > The memset is not needed as recallocarray(3) does the zeroing already. > (I also think the a->data == NULL check in the if clause is redundant, > but I'm just suggesting to remove a bit that confused me) ok, -Otto > >

Re: shrinking and growing reallocs: a theoretical? bad case for performance

2020-09-02 Thread Otto Moerbeek
On Tue, Sep 01, 2020 at 11:56:36AM +0100, Stuart Henderson wrote: > On 2020/08/31 08:39, Otto Moerbeek wrote: > > A question from Theo made me think about realloc and come up with a > > particular bad case for performance. I do not know if it happens in > > practice, but

Re: shrinking and growing reallocs: a theoretical? bad case for performance

2020-08-31 Thread Otto Moerbeek
On Mon, Aug 31, 2020 at 11:25:51AM -0600, Theo de Raadt wrote: > > Taking advantage of the sparse address space is smart and as 64-bit > > is now the norm, that space is even sparser. > > Fundamentally this is moving various forms of pressure to the kernel, > which does not do the best job yet.

Re: shrinking and growing reallocs: a theoretical? bad case for performance

2020-08-31 Thread Otto Moerbeek
On Mon, Aug 31, 2020 at 08:28:25AM -0400, David Higgs wrote: > On Mon, Aug 31, 2020 at 2:41 AM Otto Moerbeek wrote: > > > Hi, > > > > A question from Theo made me think about realloc and come up with a > > particular bad case for performance. I do not know

shrinking and growing reallocs: a theoretical? bad case for performance

2020-08-31 Thread Otto Moerbeek
Hi, A question from Theo made me think about realloc and come up with a particular bad case for performance. I do not know if it happens in practice, but it was easy to create a test program to hit the case. We're talking allocation >= a page here. Smaller allocation follow different rules. If

Re: ntpd: go into unsynced mode

2020-08-30 Thread Otto Moerbeek
On Sat, Aug 22, 2020 at 03:51:48PM +0200, Otto Moerbeek wrote: > Hi, > > At the moment ntpd never goes into unsynced mode if network > connectivity is lost. The code to do that is only triggered when a > pakcet is received, which does not happen. > > This diff fixes that b

Re: ntpd: go into unsynced mode

2020-08-25 Thread Otto Moerbeek
On Tue, Aug 25, 2020 at 07:05:31PM +0200, Matthias Schmidt wrote: > Hi Otto, > > * Otto Moerbeek wrote: > > Hi, > > > > At the moment ntpd never goes into unsynced mode if network > > connectivity is lost. The code to do that is only triggered when a &

ntpd: go into unsynced mode

2020-08-22 Thread Otto Moerbeek
Hi, At the moment ntpd never goes into unsynced mode if network connectivity is lost. The code to do that is only triggered when a pakcet is received, which does not happen. This diff fixes that by going into unsynced mode if no time data was processed for a while. An earlier version of this

Re: adjtime(2): distribute skew along arbitrary runtime period

2020-07-16 Thread Otto Moerbeek
On Wed, Jul 15, 2020 at 09:08:29AM -0500, Scott Cheloha wrote: > Hi, > > adjtime(2) skews the clock at up to 5000ppm per second. The way this > actually happens is pretty straightforward: at the start of every UTC > second we call ntp_update_second() from tc_windup() and reset > th_adjustment.

Re: fsck_ffs: faster with lots of cylinder groups

2020-07-12 Thread Otto Moerbeek
On Sun, Jul 12, 2020 at 11:07:05AM +0200, Solene Rapenne wrote: > On Sun, 12 Jul 2020 09:13:47 +0200 > Otto Moerbeek : > > > On Mon, Jun 29, 2020 at 02:30:41PM +0200, Otto Moerbeek wrote: > > > > > On Sun, Jun 21, 2020 at 03:35:21PM +0200, Otto Moerb

Re: fsck_ffs: faster with lots of cylinder groups

2020-07-12 Thread Otto Moerbeek
On Mon, Jun 29, 2020 at 02:30:41PM +0200, Otto Moerbeek wrote: > On Sun, Jun 21, 2020 at 03:35:21PM +0200, Otto Moerbeek wrote: > > > Hi, > > > > both phase 1 and phase 5 need cylinder group metadata. This diff > > keeps the cg data read in phase 1 i

Re: Undefined Behavior at jsmn.c

2020-07-12 Thread Otto Moerbeek
On Sun, Jul 12, 2020 at 09:57:02AM +0430, Ali Farzanrad wrote: > Hi @tech, > > I was comparing jsmn.c in acme-client with jsmn.c in FreeBSD [1]. > I found a switch without a default case which is an undefined behavior: > > @@ -69,6 +69,8 @@ > case '\t' : case '\r' : case

Re: adjfreq(2): limit adjustment to prevent overflow during tc_windup()

2020-07-03 Thread Otto Moerbeek
On Thu, Jul 02, 2020 at 08:27:58PM -0500, Scott Cheloha wrote: > Hi, > > When we recompute the scaling factor during tc_windup() there is an > opportunity for arithmetic overflow/underflow when we add the NTP > adjustment into the scale: > >649 scale = (u_int64_t)1 << 63; >650

Re: fsck_ffs: faster with lots of cylinder groups

2020-06-29 Thread Otto Moerbeek
On Sun, Jun 21, 2020 at 03:35:21PM +0200, Otto Moerbeek wrote: > Hi, > > both phase 1 and phase 5 need cylinder group metadata. This diff > keeps the cg data read in phase 1 in memory to be used by phase 5 if > possible. From FreeBSD. > > -Otto > >

Re: obsd 6.7 - ntpd error msg

2020-06-22 Thread Otto Moerbeek
On Thu, Jun 18, 2020 at 11:41:17AM +0200, Otto Moerbeek wrote: > On Thu, Jun 18, 2020 at 09:57:34AM +0200, Salvatore Cuzzilla wrote: > > > Perfect, tnx! > > > > On 18.06.2020 07:58, Otto Moerbeek wrote: > > > On Wed, Jun 17, 2020 at 10:53:54PM +0200, Salvatore

fsck_ffs: faster with lots of cylinder groups

2020-06-21 Thread Otto Moerbeek
Hi, both phase 1 and phase 5 need cylinder group metadata. This diff keeps the cg data read in phase 1 in memory to be used by phase 5 if possible. From FreeBSD. -Otto On an empty 30T fileystem: $ time obj/fsck_ffs -f /dev/sd3a 2m44.10s real 0m13.21s user 0m07.38s system

Re: obsd 6.7 - ntpd error msg

2020-06-18 Thread Otto Moerbeek
On Thu, Jun 18, 2020 at 09:57:34AM +0200, Salvatore Cuzzilla wrote: > Perfect, tnx! > > On 18.06.2020 07:58, Otto Moerbeek wrote: > > On Wed, Jun 17, 2020 at 10:53:54PM +0200, Salvatore Cuzzilla wrote: > > > > > Hi Otto here the logs (multitail

Re: obsd 6.7 - ntpd error msg

2020-06-17 Thread Otto Moerbeek
9:23 -ksh ToTo@obsd ~ $ OK, now we're getting somewhere. It always helps to provide lots of information form the start. The message is generated by ntpd being stopped. It is harmless, though it is actually wrong, it's a pip read error. So nothing to worry about. I'll see if the log level should be

Re: obsd 6.7 - ntpd error msg

2020-06-17 Thread Otto Moerbeek
- And show the log lines, all of them -Otto > > On 17.06.2020 20:51, Otto Moerbeek wrote: > > On Wed, Jun 17, 2020 at 04:50:46PM +0200, Salvatore Cuzzilla wrote: > > > > > Hi Folks, > > > > > > when I restart

Re: obsd 6.7 - ntpd error msg

2020-06-17 Thread Otto Moerbeek
On Wed, Jun 17, 2020 at 04:50:46PM +0200, Salvatore Cuzzilla wrote: > Hi Folks, > > when I restart ntpd I see this msg in /var/log/daemon: > > Jun 17 16:19:41 obsd ntpd[92699]: pipe write error (from main): No suchfile > or directory > > however, time seems to be in sync: > >

sparc64: bootblocks vs ofwboot load address

2020-06-05 Thread Otto Moerbeek
Hi, Miod remarked the overwriting of the bootblocks actually is a regression I introduced. So teintroduce the lost comment and load ofwboot at 0x6000. OK? -Otto Index: bootblk.fth === RCS file:

Re: filesystem code integer and many inodes

2020-06-02 Thread Otto Moerbeek
On Fri, May 29, 2020 at 09:30:04AM +0200, Otto Moerbeek wrote: > On Thu, May 28, 2020 at 12:54:41PM -0600, Todd C. Miller wrote: > > > On Thu, 28 May 2020 20:53:07 +0200, Otto Moerbeek wrote: > > > > > Here's the separate diff for the prefcg loops. From F

Re: sparc64 boot issue on qemu

2020-05-31 Thread Otto Moerbeek
On Sun, May 31, 2020 at 09:49:34AM +0100, Mark Cave-Ayland wrote: > On 30/05/2020 10:54, Otto Moerbeek wrote: > > > https://cdn.openbsd.org/pub/OpenBSD/snapshots/sparc64/ > > contains the unpatched miniroot. > > > > https://www.drijf.net/openbsd/disk.qcow2 &g

Re: sparc64 boot issue on qemu

2020-05-30 Thread Otto Moerbeek
On Sat, May 30, 2020 at 10:11:08AM +0100, Mark Cave-Ayland wrote: > On 30/05/2020 10:03, Otto Moerbeek wrote: > > > Hi, > > > > thanks for the hints, but an unpatched 6.7 miniroot still fails to > > boot for me > > > > qemu-system-sparc64 -machine sun4

Re: sparc64 boot issue on qemu

2020-05-30 Thread Otto Moerbeek
On Sat, May 30, 2020 at 09:29:36AM +0100, Mark Cave-Ayland wrote: > On 29/05/2020 23:56, Jason A. Donenfeld wrote: > > > Oh that's a nice observation about `boot disk -V`. Doing so actually > > got me booting up entirely: > > > > $ qemu-img convert -O qcow2 miniroot66.fs disk.qcow2 > > $

sparc64 boot issue on qemu

2020-05-29 Thread Otto Moerbeek
On Thu, May 28, 2020 at 10:11:28AM +0200, Otto Moerbeek wrote: > On Thu, May 28, 2020 at 01:21:21AM -0600, Jason A. Donenfeld wrote: > > > On Thu, May 28, 2020 at 1:19 AM Otto Moerbeek wrote: > > > Of course.., I was running it from a !wxallowed mount. BTW, qemu is in &g

Re: filesystem code integer and many inodes

2020-05-29 Thread Otto Moerbeek
On Fri, May 29, 2020 at 09:30:04AM +0200, Otto Moerbeek wrote: > On Thu, May 28, 2020 at 12:54:41PM -0600, Todd C. Miller wrote: > > > On Thu, 28 May 2020 20:53:07 +0200, Otto Moerbeek wrote: > > > > > Here's the separate diff for the prefcg loops. From F

Re: filesystem code integer and many inodes

2020-05-29 Thread Otto Moerbeek
On Thu, May 28, 2020 at 12:54:41PM -0600, Todd C. Miller wrote: > On Thu, 28 May 2020 20:53:07 +0200, Otto Moerbeek wrote: > > > Here's the separate diff for the prefcg loops. From FreeBSD. > > OK millert@ > > - todd > And here's the updated diff against -current.

Re: filesystem code integer and many inodes

2020-05-28 Thread Otto Moerbeek
On Tue, May 26, 2020 at 04:11:50PM +0200, Otto Moerbeek wrote: > On Tue, May 26, 2020 at 03:54:15PM +0200, Otto Moerbeek wrote: > > > On Tue, May 26, 2020 at 07:51:28AM -0600, Todd C. Miller wrote: > > > > > On Tue, 26 May 2020 12:07:21 +0200, Otto Moerbeek wrote

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-28 Thread Otto Moerbeek
On Thu, May 28, 2020 at 01:21:21AM -0600, Jason A. Donenfeld wrote: > On Thu, May 28, 2020 at 1:19 AM Otto Moerbeek wrote: > > Of course.., I was running it from a !wxallowed mount. BTW, qemu is in > > packages, no need to build it yourself. > > Sure, but now I've been

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-28 Thread Otto Moerbeek
On Thu, May 28, 2020 at 01:05:59AM -0600, Jason A. Donenfeld wrote: > On Thu, May 28, 2020 at 12:15 AM Otto Moerbeek wrote: > > > > On Wed, May 27, 2020 at 11:28:09PM -0600, Jason A. Donenfeld wrote: > > > > > Hi Otto, > > > > > > On W

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-28 Thread Otto Moerbeek
On Wed, May 27, 2020 at 11:28:09PM -0600, Jason A. Donenfeld wrote: > Hi Otto, > > On Wed, May 27, 2020 at 4:07 AM Otto Moerbeek wrote: > > Although I'm not terribly interested in bugs that are only seen (s0 > > far) using emulation, please send me the details on ho

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Otto Moerbeek
On Wed, May 27, 2020 at 03:14:29AM -0600, Jason A. Donenfeld wrote: > One interesting quirk in doing this on qemu is that the 6.7 and > -current kernel both crash: > > Loading FCode image... > Loaded 6882 bytes > entry point is 0x4000 > Evaluating FCode... > OpenBSD IEEE 1275 Bootblock 2.0 >

  1   2   3   4   5   6   7   8   >