Re: More on mimmutable

2022-11-17 Thread Otto Moerbeek
On Thu, Nov 17, 2022 at 08:10:05PM -0700, Theo de Raadt wrote: > So this static executable is completely immutable, except for the > OPENBSD_MUTABLE region. This annotation is used in one place now, deep > inside libc's malloc(3) code, where a piece of code flips a data structure > between

Re: M1 Macmini lost hw.cpuspeed

2022-10-24 Thread Otto Moerbeek
On Mon, Oct 24, 2022 at 04:15:40PM +0200, Mark Kettenis wrote: > > Date: Mon, 24 Oct 2022 14:52:00 +0200 > > From: Robert Nagy > > > > On 24/10/22 14:49 +0200, Theo Buehler wrote: > > > On Mon, Oct 24, 2022 at 09:24:14AM +0200, Otto Moerbeek wrote: > > >

M1 Macmini lost hw.cpuspeed

2022-10-24 Thread Otto Moerbeek
Hello, after updating my M1 macmini after my vacatiuon to the latest snap it seems to have lost a few sysctl nodes, making apm(8) fail: [otto@macmini:4]$ ktrace apm Battery state: unknown, 0% remaining, unknown life estimate AC adapter state: not known Performance adjustment mode: invalid (0

malloc diff

2022-10-21 Thread Otto Moerbeek
Hi, this diff has been sent out earlier, but now that more or the immutable parts are in, it is time to test it in this new environment. Thanks, -Otto Index: stdlib/malloc.c === RCS file:

Re: malloc: prep for immutable pages

2022-10-05 Thread Otto Moerbeek
On Wed, Oct 05, 2022 at 02:47:19PM +0200, Marc Espie wrote: > On Tue, Oct 04, 2022 at 10:15:51AM -0600, Theo de Raadt wrote: > > A note on why this chance is coming. > > > > malloc.c (as it is today), does mprotects back and forth between RW and > > R, to protect an internal object. This object

malloc: prep for immutable pages

2022-09-29 Thread Otto Moerbeek
Hi, Rearrange things so that we do not have to flip protection of r/o pages back and forth when swicthing from single-threaded to multi-threaded. Also saves work in many cases by not initing pools until they are used: the pool used for MAP_CONCEAL pages is not used by very many processes and if

Re: Request for testing malloc and multi-threaded applications

2022-09-27 Thread Otto Moerbeek
On Tue, Sep 27, 2022 at 03:31:12PM +0200, Renaud Allard wrote: > On 1/16/19 19:09, Otto Moerbeek wrote: > > On Wed, Jan 16, 2019 at 01:25:25PM +, Stuart Henderson wrote: > > > > > On 2019/01/04 08:09, Otto Moerbeek wrote: > > > > On Thu, Dec 27, 2018 at 0

Re: installer: zap fdisk.8.gz and disklabel.8.gz

2022-08-25 Thread Otto Moerbeek
On Thu, Aug 25, 2022 at 07:32:16PM +, Miod Vallat wrote: > > > The ability to be able to read the manual pages from the binaries > > > themselves, when running is interactive mode, is an intentional feature > > > and the reason they embed a gzipped version of the formatted manpage. > > > >

Re: Race in disk_attach_callback?

2022-07-13 Thread Otto Moerbeek
On Wed, Jul 13, 2022 at 02:18:53PM +0200, Otto Moerbeek wrote: > Hi, > > after a prompt from stsp@ and florian@, reporting that newfs_msdos > fails when given an $duid.i argument, I set down to see what could be > going on. My test using an USB stick failed to reprdouce the pr

Race in disk_attach_callback?

2022-07-13 Thread Otto Moerbeek
Hi, after a prompt from stsp@ and florian@, reporting that newfs_msdos fails when given an $duid.i argument, I set down to see what could be going on. My test using an USB stick failed to reprdouce the problem. Then I started using a vnd, and that shows the issue (once in a while). The feeling is

Re: quiz(6): update european countries

2022-07-04 Thread Otto Moerbeek
On Mon, Jul 04, 2022 at 05:44:33PM -0400, Daniel Dickman wrote: > > > On Sun, 3 Jul 2022, Daniel Dickman wrote: > > > On Sat, Jul 2, 2022 at 9:26 PM Ben Fuller wrote: > > > > > > I noticed Montenegro doesn't have an entry. Presumably this file hasn't > > > been updated since before 2006! > >

Re: dig(1): SVCB and HTTPS RR types

2022-07-03 Thread Otto Moerbeek
On Sun, Jul 03, 2022 at 07:47:27AM +0200, Florian Obser wrote: > anyone? Looks good and works for me, ok. -Otto > > On 2022-06-25 13:15 +02, Florian Obser wrote: > > See https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ > > > > $ ./obj/dig @8.8.8.8 +norec

Re: a few fixes for cat bugs

2022-07-02 Thread Otto Moerbeek
On Sat, Jul 02, 2022 at 08:38:53AM +0100, Leah Rowe wrote: > > Hi Otto, > > > Your fixes are not ok. See comment inline. > > The other person (Theo) who responded, raised the same concerns as you. > Sorry for wasting your time. I've reverted the patches myself, locally, > knowing now that I

Re: a few fixes for cat bugs

2022-07-02 Thread Otto Moerbeek
On Sat, Jul 02, 2022 at 03:15:21AM +0100, Leah Rowe wrote: > > Hi, > > I've been playing around with a few OpenBSD userland programs. By that, > I mean I've been studying them extensively. I'm working on creating a > busybox-like userland for Linux with musl libc, and I need quality code > so I

Re: Picky, but much more efficient arc4random_uniform!

2022-05-18 Thread Otto Moerbeek
On Wed, May 18, 2022 at 05:08:02PM +1000, Damien Miller wrote: > On Wed, 18 May 2022, Otto Moerbeek wrote: > > > instrumenting the code to count the number of arc4random calls I see thsi: > > > > openbsd; elapsed = 2.835819; calls = 12340949 > > bitmask; elapse

Re: Picky, but much more efficient arc4random_uniform!

2022-05-17 Thread Otto Moerbeek
On Wed, May 18, 2022 at 02:50:28PM +1000, Damien Miller wrote: > On Tue, 17 May 2022, Raimo Niskanen wrote: > > > Why reinvent the wheel? > > > > Here is a pretty good walkthrough of established methods: > > > > https://www.pcg-random.org/posts/bounded-rands.html > > > > It sounds to me

Re: Picky, but much more efficient arc4random_uniform!

2022-05-15 Thread Otto Moerbeek
On Sun, May 15, 2022 at 08:57:09AM -0300, Crystal Kolipe wrote: > On Sun, May 15, 2022 at 11:44:29AM +0200, Otto Moerbeek wrote: > > On Sun, May 15, 2022 at 04:27:30AM -0500, Luke Small wrote: > > > How did someone prove the current implementation was cryptographically > &g

Re: Picky, but much more efficient arc4random_uniform!

2022-05-15 Thread Otto Moerbeek
the verification. -Otto > > On Sun, May 15, 2022 at 3:15 AM Otto Moerbeek wrote: > > > On Sun, May 15, 2022 at 01:12:28AM -0500, Luke Small wrote: > > > > > This is version 1, which I was pretty sure was secure. > > > > > > I revamped

Re: Picky, but much more efficient arc4random_uniform!

2022-05-15 Thread Otto Moerbeek
On Sun, May 15, 2022 at 01:12:28AM -0500, Luke Small wrote: > This is version 1, which I was pretty sure was secure. > > I revamped it with a few features and implanted the binary search for 'bit' > > in most cases, which aren't intentionally worst-case, it's pretty darned > fast! > > This is

Re: Picky, but much more efficient arc4random_uniform!

2022-05-15 Thread Otto Moerbeek
On Sat, May 14, 2022 at 05:03:17PM -0700, Philip Guenther wrote: > On Sun, 15 May 2022, Steffen Nurpmeso wrote: > > Stuart Henderson wrote in > ... > > |what's the perceived problem you're wanting to solve? and does that > > |problem actually exist in the first place? > > > > The problem is

Re: Picky, but much more efficient arc4random_uniform!

2022-05-14 Thread Otto Moerbeek
On Sat, May 14, 2022 at 05:48:10AM -0500, Luke Small wrote: > arc4random_uniform_fast2 that I made, streams in data from arc4random() and > uses the datastream directly and uses it as a bit by bit right "sliding > window" in the last loop. arc4random_uniform() uses a modulus which I is > simple

Re: Picky, but much more efficient arc4random_uniform!

2022-05-14 Thread Otto Moerbeek
In general, wasting some arc4random bits is not a problem at all. I see a lot of code with no demonstration, explanation or proof why it would be correct (i.e. produces uniform results). You only talk about speed. The current code might not be optimal, but at least it is very clear it's correct.

Re: stop using mquery(2) inside realloc(3)

2022-05-14 Thread Otto Moerbeek
On Fri, May 13, 2022 at 08:21:19PM -0700, Philip Guenther wrote: > If you try to grow a 'large' (at least half a page) allocation with > realloc(3), it'll try to extend the memory mapping for it and if that > works it won't need to move it. (on a side note: it does not do anything at all if

Re: pf igmp icmp6 multicast router alert

2022-04-28 Thread Otto Moerbeek
On Thu, Apr 28, 2022 at 12:36:40AM +0200, Alexander Bluhm wrote: > On Wed, Apr 27, 2022 at 11:47:45PM +0200, Alexander Bluhm wrote: > > New diff: > > - make off and end relative to opts array > > - check length of IPv4 options > > - fix call to pf_walk_option > > - add case IP6OPT_PADN > > - add

Re: errata70.html - update the 7.1 link

2022-04-22 Thread Otto Moerbeek
On Fri, Apr 22, 2022 at 07:22:18PM -0400, Horia Racoviceanu wrote: > - change 7.1 link from errata70.html to errata71.html > Index: errata70.html > === > RCS file: /cvs/www/errata70.html,v > retrieving revision 1.25 > diff -u -p

Re: pf igmp icmp6 multicast router alert

2022-04-21 Thread Otto Moerbeek
On Thu, Apr 21, 2022 at 07:08:38PM +0200, Alexander Bluhm wrote: > Hi, > > IGMP and ICMP6 for multicast packets have router alert options. > Per default pf drops all IP packets with options. Usually people > ask what is wrong until someone points out that they have to use a > pf rule with

Re: fix very small ntpd leak

2022-03-24 Thread Otto Moerbeek
On Thu, Mar 24, 2022 at 10:34:52AM +1000, Jonathan Matthew wrote: > On Wed, Mar 23, 2022 at 04:59:06PM +0100, Otto Moerbeek wrote: > > On Wed, Mar 23, 2022 at 09:09:01PM +1000, Jonathan Matthew wrote: > > > > > We noticed that the ntpd engine process was getting a bit

Re: fix very small ntpd leak

2022-03-23 Thread Otto Moerbeek
On Wed, Mar 23, 2022 at 09:09:01PM +1000, Jonathan Matthew wrote: > We noticed that the ntpd engine process was getting a bit big on some boxes > that we'd accidentally cut off from the ntp servers (routing is hard). > Reading through the code, I noticed the 'query' member of struct ntp_peer > is

Re: request for testing: malloc and large allocations

2022-02-25 Thread Otto Moerbeek
On Tue, Feb 01, 2022 at 08:00:36AM +0100, Otto Moerbeek wrote: > On Fri, Jan 28, 2022 at 05:17:48PM +0100, Otto Moerbeek wrote: > > > On Fri, Jan 28, 2022 at 04:33:28PM +0100, Alexander Bluhm wrote: > > > > > On Sun, Jan 09, 2022 at 02:54:43PM +0100, Otto Moerbe

Re: tcpdump core's on the latest snapshot

2022-02-13 Thread Otto Moerbeek
On Sun, Feb 13, 2022 at 12:54:19PM +0100, Otto Moerbeek wrote: > On Sun, Feb 13, 2022 at 01:12:34PM +0300, Mikhail wrote: > > > Running this command on the latest snapshot produces core file for me: > > > > doas tcpdump -i urtwn0 proto ip6 BTW, the proper way to filte

Re: tcpdump core's on the latest snapshot

2022-02-13 Thread Otto Moerbeek
On Sun, Feb 13, 2022 at 01:12:34PM +0300, Mikhail wrote: > Running this command on the latest snapshot produces core file for me: > > doas tcpdump -i urtwn0 proto ip6 > > Core details: > > misha:/home/misha:3959$ doas lldb --core tcpdump.core tcpdump > (lldb) target create "tcpdump" --core

Re: request for testing: malloc and large allocations

2022-02-05 Thread Otto Moerbeek
On Sat, Feb 05, 2022 at 08:07:42PM +0100, Jan Stary wrote: > On Feb 05 17:35:46, o...@drijf.net wrote: > > On Sat, Feb 05, 2022 at 05:22:50PM +0100, Jan Stary wrote: > > > > > On Feb 02 00:04:37, alexander.bl...@gmx.net wrote: > > > > On Tue, Feb 01, 2022 at 0

Re: request for testing: malloc and large allocations

2022-02-05 Thread Otto Moerbeek
On Sat, Feb 05, 2022 at 05:22:50PM +0100, Jan Stary wrote: > On Feb 02 00:04:37, alexander.bl...@gmx.net wrote: > > On Tue, Feb 01, 2022 at 08:00:36AM +0100, Otto Moerbeek wrote: > > > > Are you running with any malloc flags? > > > > > > This bug report ena

Re: request for testing: malloc and large allocations

2022-01-31 Thread Otto Moerbeek
On Fri, Jan 28, 2022 at 05:17:48PM +0100, Otto Moerbeek wrote: > On Fri, Jan 28, 2022 at 04:33:28PM +0100, Alexander Bluhm wrote: > > > On Sun, Jan 09, 2022 at 02:54:43PM +0100, Otto Moerbeek wrote: > > > currently malloc does cache a number of free'ed regions up

Re: UBSan instrumentation vs -fno-wrapv

2022-01-30 Thread Otto Moerbeek
On Sun, Jan 30, 2022 at 04:46:36PM -0800, Greg Steuck wrote: > In case somebody hits this, here's a resolved issue: -fno-wrapv is > matters for UBSan coverage. > > Confusion starts with: > > $ uname -srm; cat a.c && clang -fsanitize=undefined a.c -c -o a.o && nm a.o > OpenBSD 7.0 amd64 > int

Re: request for testing: malloc and large allocations

2022-01-28 Thread Otto Moerbeek
On Fri, Jan 28, 2022 at 04:33:28PM +0100, Alexander Bluhm wrote: > On Sun, Jan 09, 2022 at 02:54:43PM +0100, Otto Moerbeek wrote: > > currently malloc does cache a number of free'ed regions up to 128k in > > size. This cache is indexed by size (in # of pages), so it is very >

Re: request for testing: malloc and large allocations

2022-01-25 Thread Otto Moerbeek
On Sat, Jan 22, 2022 at 09:25:25AM +0100, Otto Moerbeek wrote: > On Mon, Jan 17, 2022 at 08:42:47AM +0100, Otto Moerbeek wrote: > > > On Sun, Jan 09, 2022 at 02:54:43PM +0100, Otto Moerbeek wrote: > > > > > Hi, > > > > > > currently malloc does

Re: request for testing: malloc and large allocations

2022-01-22 Thread Otto Moerbeek
On Mon, Jan 17, 2022 at 08:42:47AM +0100, Otto Moerbeek wrote: > On Sun, Jan 09, 2022 at 02:54:43PM +0100, Otto Moerbeek wrote: > > > Hi, > > > > currently malloc does cache a number of free'ed regions up to 128k in > > size. This cache is indexed by size

Re: request for testing: malloc and large allocations

2022-01-16 Thread Otto Moerbeek
On Sun, Jan 09, 2022 at 02:54:43PM +0100, Otto Moerbeek wrote: > Hi, > > currently malloc does cache a number of free'ed regions up to 128k in > size. This cache is indexed by size (in # of pages), so it is very > quick to check. > > Some programs allocate and dealloca

request for testing: malloc and large allocations

2022-01-09 Thread Otto Moerbeek
Hi, currently malloc does cache a number of free'ed regions up to 128k in size. This cache is indexed by size (in # of pages), so it is very quick to check. Some programs allocate and deallocate larger allocations in a frantic way. Accodomate those programs by also keeping a cache of regions

Re: cat(1): always use a 64K buffer

2021-12-13 Thread Otto Moerbeek
On Mon, Dec 13, 2021 at 02:52:50AM -0600, Scott Cheloha wrote: > > On Dec 13, 2021, at 01:13, Otto Moerbeek wrote: > > > > ´╗┐On Sun, Dec 12, 2021 at 07:15:51PM -0600, Scott Cheloha wrote: > > > >> cat(1) sizes its I/O buffer according to the st_blksize of the

Re: cat(1): always use a 64K buffer

2021-12-12 Thread Otto Moerbeek
On Sun, Dec 12, 2021 at 07:15:51PM -0600, Scott Cheloha wrote: > cat(1) sizes its I/O buffer according to the st_blksize of the first > file it processes. We don't do this very often in the tree. I'm not > sure if we should trust st_blksize. > > It would be simpler to just choose a value that

Re: asr(3): strip AD flag in responses

2021-11-21 Thread Otto Moerbeek
On Sun, Nov 21, 2021 at 04:51:45PM +0100, Florian Obser wrote: > On 2021-11-20 21:16 +01, Otto Moerbeek wrote: > > On Sat, Nov 20, 2021 at 06:44:58PM +0100, Florian Obser wrote: > > > >> On 2021-11-20 18:41 +01, Florian Obser wrote: > >> > On 2021-1

Re: asr(3): strip AD flag in responses

2021-11-20 Thread Otto Moerbeek
On Sat, Nov 20, 2021 at 06:44:58PM +0100, Florian Obser wrote: > On 2021-11-20 18:41 +01, Florian Obser wrote: > > On 2021-11-20 18:19 +01, Florian Obser wrote: > > > >> +/* > >> + * Clear AD flag in the answer. > >> + */ > >> +static void > >> +clear_ad(struct asr_result *ar) > >> +{ > >> +

Re: asr(3): strip AD flag in responses

2021-11-20 Thread Otto Moerbeek
On Sat, Nov 20, 2021 at 02:40:59PM +0100, Otto Moerbeek wrote: > On Sat, Nov 20, 2021 at 12:20:32PM +0100, Florian Obser wrote: > > > The Authentic Data (AD) flag indicates that the nameserver validated > > the response using DNSSEC. For clients to trust this the nameserve

Re: asr(3): strip AD flag in responses

2021-11-20 Thread Otto Moerbeek
On Sat, Nov 20, 2021 at 12:20:32PM +0100, Florian Obser wrote: > The Authentic Data (AD) flag indicates that the nameserver validated > the response using DNSSEC. For clients to trust this the nameserver > and the path to the nameserver must be trusted. In the general case > this is not true. >

Re: [PATCH] Change maximum size of /usr/src to 3G for autoinstall

2021-11-07 Thread Otto Moerbeek
On Sun, Nov 07, 2021 at 07:44:57PM +0300, Mikhail wrote: > On Sat, Oct 30, 2021 at 11:39:54AM +0300, Mikhail wrote: > > On Sun, Oct 24, 2021 at 02:17:25PM +0300, Mikhail wrote: > > > On Sun, Oct 24, 2021 at 11:32:26AM +0100, Stuart Henderson wrote: > > > > The minimum needs to go up too, a cvs

Re: Missing semicolon in snmpd/parse.y

2021-10-20 Thread Otto Moerbeek
On Wed, Oct 20, 2021 at 01:58:03PM +0200, Gerhard Roth wrote: > Hi, > > the rule for 'listen_udptcp' is missing a semicolon at its end. > > I have no idea what yacc does to the following 'port' rule without > that semicolon. Looks like the generated c code is the same; ok otto@ -Otto

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:

  1   2   3   4   5   6   7   8   9   >