Re: Adding fstab(5) fs_mntops to mount_nfs(8)

On Mon, Mar 11, 2019 at 12:16:59PM -0400, Kurt Mosiejczuk wrote: > On Mon, Mar 11, 2019 at 04:51:00PM +0100, Otto Moerbeek wrote: > > > Looking at mount_nfs.c, I don't see all options you mention in the > > mopts array. Where did you find them? e.g. udp does not exis

Re: [patch] Re: Possible sasyncd memory leak ?

I was going to test your diff but it does not apply. Your mailer seems to convert spaces and or tabs to funny char sequences. Please fix (test by mailing to yourself and applying with patch(1)) and resend, -Otto

Re: Adding fstab(5) fs_mntops to mount_nfs(8)

On Mon, Mar 11, 2019 at 09:40:16AM -0400, Kurt Mosiejczuk wrote: > As far as I can tell, no man page documents the fs_mntops form of the > mount_nfs(8) options for fstab(5). Most of us who use them either know > from some other documentation, reading the source, or just doing a > copy-paste from

Re: [patch] Re: Possible sasyncd memory leak ?

On Sun, Mar 10, 2019 at 02:41:35PM +0100, Michał Koc wrote: > W dniu 10.03.2019 o 08:10, Otto Moerbeek pisze: > > On Sat, Mar 09, 2019 at 11:19:11PM +0100, Michał Koc wrote: > > > > > W dniu 09.03.2019 o 12:43, Otto Moerbeek pisze: > > > > On Sat, Mar 09,

Re: acme-client: remove free() before exits in main()

On Sat, Mar 09, 2019 at 08:50:10AM -0700, Theo de Raadt wrote: > Otto Moerbeek wrote: > > > On Sat, Mar 09, 2019 at 11:23:22AM +0100, Sebastian Benoit wrote: > > > > > We free a few strings in main(), some others we dont. We should either > > > free() all s

Re: acme-client: remove free() before exits in main()

On Sat, Mar 09, 2019 at 11:23:22AM +0100, Sebastian Benoit wrote: > We free a few strings in main(), some others we dont. We should either > free() all strings consistently or not free them at all, because it does not > hurt to keep them until exit(). > > The chances of the main() function being

Re: nm(1): return on malloc error

On Sun, Mar 03, 2019 at 04:23:53PM +0100, Ingo Schwarze wrote: > Hi, > > Benjamin Baier wrote on Sat, Mar 02, 2019 at 10:10:40AM +0100: > > > On malloc error symtab is unmapped, so proceeding on will lead > > to a NULL pointer dereference. > > When malloc fails we should return like the MMAP

Re: bgpd use long long instead of int64_t

On Tue, Feb 19, 2019 at 09:28:36AM +0100, Claudio Jeker wrote: > On Tue, Feb 19, 2019 at 12:10:25AM +0100, Andreas Kusalananda Kähäri wrote: > > On Mon, Feb 18, 2019 at 10:11:03PM +0100, Mark Kettenis wrote: > > > > Date: Mon, 18 Feb 2019 21:59:38 +0100 > > > > From: Claudio Jeker > > > > > > >

Re: man -> vim

On Fri, Feb 15, 2019 at 11:19:57AM +0100, Oleg Pahl wrote: > Hi @all, > > Today I try to work with man pages using *vim*. > > *# man man | vim -* > > why i see raw (a lot of special char.) data by default? is it ok? > > *# ma man | less * > > I see no special characters. looks very good. >

qsort comparision function bug

Hi, This code is buggy, since subtraction and then casting to int will not produce the right result if the values are too far apart. There must be more like this in the tree any volunteers? In general, you don't want to do subtraction, even for ints. For example: compare INT_MIN and 1.

Re: [PATCH] systat reports inaccurate statistics for disk i/o speed

On Sat, Jan 19, 2019 at 09:30:12PM +0900, Bryan Linton wrote: > Hello tech@, > > I'd appreciate it if someone could review both this patch and my > analysis. > > > PROBLEM > --- > When running systat, the vmstat page shows inaccurate numbers for > disk i/o speed (likely only on

Re: Request for testing malloc and multi-threaded applications

an/Hoard > > [3] https://github.com/emeryberger/Hoard/blob/master/doc/berger-asplos2000.pdf > > On Wed, Dec 19, 2018 at 11:20:19AM +0100, Otto Moerbeek wrote: > > On Wed, Dec 19, 2018 at 10:52:03AM +0100, Otto Moerbeek wrote: > > > > > Hi, > > > > &g

Re: Request for testing malloc and multi-threaded applications

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 09:39:56AM +0100, Otto Moerbeek wrote: > > > > > > > > Very little feedback so far. This diff can only give me val

Re: Request for testing malloc and multi-threaded applications

On Thu, Dec 27, 2018 at 09:39:56AM +0100, Otto Moerbeek wrote: > > Very little feedback so far. This diff can only give me valid feedback > if the coverage of systems and use cases is wide. If I do not get > more feedback, I have to base my decisions on my own testing, which >

Re: Request for testing malloc and multi-threaded applications

, start your tests! -Otto On Wed, Dec 19, 2018 at 11:20:19AM +0100, Otto Moerbeek wrote: > On Wed, Dec 19, 2018 at 10:52:03AM +0100, Otto Moerbeek wrote: > > > Hi, > > > > This diff implements a more flexible approach for the number of pools > > malloc u

Re: undocumented nfs mount option "intr"

On Fri, Dec 21, 2018 at 06:26:54PM +0100, Solene Rapenne wrote: > Otto Moerbeek wrote: > > On Thu, Dec 20, 2018 at 09:31:45AM +0100, Landry Breuil wrote: > > > > > On Thu, Dec 20, 2018 at 09:26:33AM +0100, Solene Rapenne wrote: > > > > Hi > > >

Re: undocumented nfs mount option "intr"

On Thu, Dec 20, 2018 at 09:31:45AM +0100, Landry Breuil wrote: > On Thu, Dec 20, 2018 at 09:26:33AM +0100, Solene Rapenne wrote: > > Hi > > > > fstab(5) has an example for a nfs mountpoint using the "intr" option. > > > > That option isn't documented in mount(8) or mount_nfs(8) and in fact,

Re: Request for testing malloc and multi-threaded applications

On Wed, Dec 19, 2018 at 10:52:03AM +0100, Otto Moerbeek wrote: > Hi, > > This diff implements a more flexible approach for the number of pools > malloc uses in the multi-threaded case. At the momemt I do not intend > to commit this as-is, I first need this to get some f

Request for testing malloc and multi-threaded applications

Hi, This diff implements a more flexible approach for the number of pools malloc uses in the multi-threaded case. At the momemt I do not intend to commit this as-is, I first need this to get some feedback on what the proper default should be. Currently the number of pools is fixed at 4. More

Re: request for testing: patch for boot loader out of mem

On Mon, Dec 17, 2018 at 10:53:26PM +0100, diego righi wrote: > Tested also the snapshot of today 2018/12/17 on same hardware but with > 500Gb disk with single big "a" partition, it works: The diff has been commited, thanks for testing. -Otto

Re: request for testing: patch for boot loader out of mem

On Thu, Dec 13, 2018 at 04:26:27PM -0500, Ted Unangst wrote: > Otto Moerbeek wrote: > > int > > biosd_diskio(int rw, struct diskinfo *dip, u_int off, int nsect, void *buf) > > { > > - return biosd_io(rw, >bios_info, off, nsect, buf); > > + int i, n, re

Re: request for testing: patch for boot loader out of mem

On Fri, Dec 14, 2018 at 09:40:28PM +0100, diego righi wrote: > Two more tests on the same machine: > 1) 320Gb disk, it works: > OpenBSD 6.4-current (GENERIC.MP) #1: Thu Dec 13 03:10:57 CET 2018 > sickn...@openbsd.sick-net:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 2130313216

Re: request for testing: patch for boot loader out of mem

On Thu, Dec 13, 2018 at 09:50:13PM -0500, Nick Holland wrote: > On 12/11/18 08:09, Otto Moerbeek wrote: > > On Mon, Dec 10, 2018 at 11:44:47AM +0100, Otto Moerbeek wrote: > > > >> On Mon, Dec 10, 2018 at 08:30:10AM +0100, Otto Moerbeek wrote: > >> > >>

Re: request for testing: patch for boot loader out of mem

On Mon, Dec 10, 2018 at 11:44:47AM +0100, Otto Moerbeek wrote: > On Mon, Dec 10, 2018 at 08:30:10AM +0100, Otto Moerbeek wrote: > > > Hi, > > > > the bootloader uses a very simple allocator for dynamic memory. It > > maintains a list of free allocations. If

Re: request for testing: patch for boot loader out of mem

On Mon, Dec 10, 2018 at 08:30:10AM +0100, Otto Moerbeek wrote: > Hi, > > the bootloader uses a very simple allocator for dynamic memory. It > maintains a list of free allocations. If it needs a block, it searches > the freelist and returns the smallest allocation that fits.

Re: malloc: simplify "not my pool" lock dance

On Thu, Dec 06, 2018 at 11:30:03AM +0100, Otto Moerbeek wrote: > Hi, > > This simpifies the lock dance when a free is done for a pointer not in > "my pool". Should reduce lock contention. > > Please review & test, especially with multithread heavy apps. This

request for testing: patch for boot loader out of mem

Hi, the bootloader uses a very simple allocator for dynamic memory. It maintains a list of free allocations. If it needs a block, it searches the freelist and returns the smallest allocation that fits. Allocation patterns like this (starting with an empty freelist) alloc(big) free(big)

Re: [Patch] Specify unit for 'every' in ifstated.conf.5

On Thu, Dec 06, 2018 at 05:33:21PM +, Jason McIntyre wrote: > On Thu, Dec 06, 2018 at 06:26:36PM +0100, Otto Moerbeek wrote: > > On Thu, Dec 06, 2018 at 05:22:36PM +, Jason McIntyre wrote: > > > > > On Thu, Dec 06, 2018 at 06:17:16PM +0100, Otto Moerbeek wrote

Re: [Patch] Specify unit for 'every' in ifstated.conf.5

On Thu, Dec 06, 2018 at 05:22:36PM +, Jason McIntyre wrote: > On Thu, Dec 06, 2018 at 06:17:16PM +0100, Otto Moerbeek wrote: > > On Thu, Dec 06, 2018 at 05:09:23PM +, Jason McIntyre wrote: > > > > > On Thu, Dec 06, 2018 at 10:21:47PM +1100,

Re: [Patch] Specify unit for 'every' in ifstated.conf.5

On Thu, Dec 06, 2018 at 05:09:23PM +, Jason McIntyre wrote: > On Thu, Dec 06, 2018 at 10:21:47PM +1100, Ross L Richardson wrote: > > > > The number is in seconds, but that's currently not specified. > > > > Wording which preserved "frequency" but made sense with "seconds" > > eluded me, so

malloc: simplify "not my pool" lock dance

Hi, This simpifies the lock dance when a free is done for a pointer not in "my pool". Should reduce lock contention. Please review & test, especially with multithread heavy apps. -Otto Index: malloc.c === RCS file:

refactor malloc a bit

Hi, this refactors the code that find an existsing allocation into a separate function. The code is currently repeated in three spots. Prepatory work to get a somehwat more efficient version of the "not-my-pool" case. Please review and test, -Otto Index: malloc.c

Re: Vim core dump

On Mon, Nov 19, 2018 at 09:13:51PM +0100, def...@posteo.de wrote: > Hi, all > > Could you be so kind to explain me why OpenBSD has no Dump core issue with > Vim : > https://github.com/vim/vim/issues/3619 > > Many thanks > > Hard question without delving deep and speding lots of time. But in

Re: malloc.conf heads up

On Wed, Nov 07, 2018 at 07:23:35AM +0100, Otto Moerbeek wrote: > Hi, > > We are moving away from the /etc/malloc.conf symbolic link to a new sysctl: > > $ sysctl vm.malloc_conf > vm.malloc_conf=C > > This will allow unveiled and chrooted proces

malloc.conf heads up

Hi, We are moving away from the /etc/malloc.conf symbolic link to a new sysctl: $ sysctl vm.malloc_conf vm.malloc_conf=C This will allow unveiled and chrooted processes to access the malloc options without having to do anything special in the code or chroot dir. As I

Re: installboot: double free

On Tue, Nov 06, 2018 at 05:32:47PM +0800, Michael Mikonos wrote: > On Tue, Nov 06, 2018 at 10:20:34AM +0100, Otto Moerbeek wrote: > > On Tue, Nov 06, 2018 at 04:35:05PM +0800, Michael Mikonos wrote: > > > > > Hello, > > > > > > In installboot's f

Re: installboot: double free

On Tue, Nov 06, 2018 at 04:35:05PM +0800, Michael Mikonos wrote: > Hello, > > In installboot's fileprefix() function r is the return value > of realpath(). If snprintf() fails free(r) happens twice--- > the second time is at label "err". From what I see the behavior > was introduced in util.c

Re: join(1) on NULL values

On Thu, Oct 18, 2018 at 04:57:23PM +0200, Martijn van Duren wrote: > On 10/18/18 16:51, Martijn van Duren wrote: > > When reviewing otto@'s diff I found the following, which was also part > > of the r1.4 import. I managed to contact michaels and he told me that he > > couldn't recollect

Re: Mention errno in printf(3) man

On Wed, Sep 05, 2018 at 12:01:59PM -0700, ge...@geoffhill.org wrote: > Right now the printf(3) family of manpages make no reference to errno. > Glancing at __vfprintf, it appears that most of the erroneous paths do > set errno. Most, but not all. Stating it will set errno in all error cases is

Re: pfctl: use strtonum in host()

On Mon, Jul 23, 2018 at 11:16:16AM +0200, Klemens Nanni wrote: > strtonum(3) is simpler than checking three cases for `q' and gives nicer > error messages. While here, use `v6mask' as maximum netmask instead of > hardcoding it. Isn't the thing called mask here actually a prefix length?

Re: Patch for column number in doas error messages

On Mon, Jul 09, 2018 at 01:52:29AM -0600, Theo de Raadt wrote: > Otto Moerbeek wrote: > > > On Mon, Jul 09, 2018 at 01:21:25AM -0600, Theo de Raadt wrote: > > > > > Phil Eaton wrote: > > > > > > > Hey, > > > > > > > >

Re: Patch for column number in doas error messages

On Mon, Jul 09, 2018 at 01:21:25AM -0600, Theo de Raadt wrote: > Phil Eaton wrote: > > > Hey, > > > > Doas currently tells you the line but not the column for syntax errors. In > > the case of a missing newline at the end of a line I was confused. So I > > added the column number to the

Re: slow vim and malloc

On Wed, Jun 06, 2018 at 11:25:43AM +0100, Stuart Henderson wrote: > On 2018/06/06 09:57, Stuart Henderson wrote: > > I've been finding vim with my standard settings really slow on OpenBSD. > > It's been bugging me for a while, but it just took about 1.2s to open > > and display a 20k patch, which

Re: slow vim and malloc

On Wed, Jun 06, 2018 at 09:57:14AM +0100, Stuart Henderson wrote: > I've been finding vim with my standard settings really slow on OpenBSD. > It's been bugging me for a while, but it just took about 1.2s to open > and display a 20k patch, which was bad enough to make me dig into it > again. > >

Re: [patch] simplify old_filename handling in ed(1)

On Wed, May 23, 2018 at 10:39:11PM +0200, Martijn van Duren wrote: > On 05/23/18 17:17, Otto Moerbeek wrote: > > On Tue, May 22, 2018 at 07:14:34PM +0200, Martijn van Duren wrote: > > > >> Does anyone still love ed enough to give me an OK? > >> > >>

Re: [patch] simplify old_filename handling in ed(1)

On Tue, May 22, 2018 at 07:14:34PM +0200, Martijn van Duren wrote: > Does anyone still love ed enough to give me an OK? > > On 05/05/18 14:36, Martijn van Duren wrote: > > Hello tech@, > > > > The following patch simplifies the filename handling for ed and removes > > a few BACKWARDS flags.

Re: unbreak gsckbc (possibly iockbc and mkbc)

On Thu, May 03, 2018 at 05:23:18PM +, Miod Vallat wrote: > sys/dev/pckbc/pckbd.c introduces a buglet, where the value computed for > local variable `table' in pckbd_set_xtscancode() in the non-translating > case, is overwritten by accident. > > Unfortunately, this means that the keyboard

Re: Behaviour of fsync() in case of write-back errors

On Fri, Apr 13, 2018 at 11:26:52AM +1200, Thomas Munro wrote: > Hello, > > I work on PostgreSQL. I don't use OpenBSD, but recently I've been > investigating how fsync() reports write-back errors on all operating > systems that people like to run PostgreSQL on: > >

Re: libkvm requires kvm_getargv before kvm_getenv when both needed

On Thu, May 03, 2018 at 07:15:24PM +0300, Vadim Zhukov wrote: > 2018-05-03 18:59 GMT+03:00 Otto Moerbeek <o...@drijf.net>: > > Yes, looks good from reading. But all te extra checks before calling > > free can go. That's idiom from a *long* time ago. > > Like that? I'

Re: libkvm requires kvm_getargv before kvm_getenv when both needed

On Thu, May 03, 2018 at 09:19:01AM -0600, Todd C. Miller wrote: > On Thu, 03 May 2018 13:58:35 +0300, Vadim Zhukov wrote: > > > Here is patch for libkvm that fixes a few memory handling problems. > > Most changes are mechanical, with some exceptions: > > > > 1. Most notable: this splits argv

Re: Explain 'S' short-hand in malloc.conf

On Thu, May 03, 2018 at 04:57:55PM +0200, Christian Ludwig wrote: > The 'S' flag in malloc.conf(5) is a short-hand for several other flags. > Explain > which flags it sets exactly. > --- > share/man/man5/malloc.conf.5 | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff

Re: [patch] Check memory allocation error in usr.bin/systat/vmstat.c

On Thu, May 03, 2018 at 09:37:50AM +0200, Otto Moerbeek wrote: > On Thu, May 03, 2018 at 02:49:03PM +0800, Nan Xiao wrote: > > > Hi tech@, > > > > A patch for usr.bin/systat/vmstat.c, apologize if I'm wrong.

Re: [patch] Check memory allocation error in usr.bin/systat/vmstat.c

On Thu, May 03, 2018 at 02:49:03PM +0800, Nan Xiao wrote: > Hi tech@, > > A patch for usr.bin/systat/vmstat.c, apologize if I'm wrong. > > Index: vmstat.c > === > RCS file: /cvs/src/usr.bin/systat/vmstat.c,v > retrieving revision

Re: route(8): improve show output

On Sun, Apr 01, 2018 at 11:09:18AM +0200, Florian Obser wrote: > On Sun, Apr 01, 2018 at 10:42:09AM +0200, Otto Moerbeek wrote: > > On Sun, Apr 01, 2018 at 10:39:39AM +0200, Florian Obser wrote: > > > > > On a backbone router with many interfaces route show scrolls f

Re: route(8): improve show output

On Sun, Apr 01, 2018 at 10:39:39AM +0200, Florian Obser wrote: > On a backbone router with many interfaces route show scrolls for quite > some time and it is difficult to see at a glance what is going on. > > Colour coding is an obvious improvement. > > The following diff sets the background

Re: disklabel,fsck_ffs: division by zero on invalid frag sizes

On Tue, Mar 27, 2018 at 07:50:18PM +0200, Otto Moerbeek wrote: > On Tue, Mar 27, 2018 at 12:46:03PM +0200, Tobias Stoeckmann wrote: > > > Resending this old diff. Adjusted to apply with -current source: > > > > Illegal fragmentation block sizes can trigger division by z

Re: disklabel,fsck_ffs: division by zero on invalid frag sizes

On Tue, Mar 27, 2018 at 12:46:03PM +0200, Tobias Stoeckmann wrote: > Resending this old diff. Adjusted to apply with -current source: > > Illegal fragmentation block sizes can trigger division by zero in the > disklabel and fsck_ffs tools. > > See this sequence of commands to reproduce: > > #

Re: armv7 ABI fix

On Tue, Feb 27, 2018 at 10:04:15PM +0100, Mark Kettenis wrote: > The "new" AAPCS-based ABI that we have been using on armv7 for a while > now requires various 64-bit types to be aligned on an 8-byte boundary. > Unfortunately we didn't realize this when we switched and didn't > adjust the

Re: arm64 MP

On Tue, Feb 20, 2018 at 08:50:14PM +0100, Otto Moerbeek wrote: > On Tue, Feb 20, 2018 at 07:52:49PM +0100, Otto Moerbeek wrote: > > > On Tue, Feb 20, 2018 at 08:58:47AM +0100, Otto Moerbeek wrote: > > > > > On Tue, Feb 20, 2018 at 08:52:20AM +0100, Mark Kettenis w

Re: arm64 MP

On Tue, Feb 20, 2018 at 07:52:49PM +0100, Otto Moerbeek wrote: > On Tue, Feb 20, 2018 at 08:58:47AM +0100, Otto Moerbeek wrote: > > > On Tue, Feb 20, 2018 at 08:52:20AM +0100, Mark Kettenis wrote: > > > > > > Date: Mon, 19 Feb 2018 13:49:48 +0100 (CET) > >

Re: arm64 MP

On Tue, Feb 20, 2018 at 08:58:47AM +0100, Otto Moerbeek wrote: > On Tue, Feb 20, 2018 at 08:52:20AM +0100, Mark Kettenis wrote: > > > > Date: Mon, 19 Feb 2018 13:49:48 +0100 (CET) > > > From: Mark Kettenis <mark.kette...@xs4all.nl> > > > > > >

Re: arm64 MP

On Tue, Feb 20, 2018 at 08:52:20AM +0100, Mark Kettenis wrote: > > Date: Mon, 19 Feb 2018 13:49:48 +0100 (CET) > > From: Mark Kettenis > > > > The diff below attempts to make the arm64 pmap "mpsafe" and enables MP > > support. This diff survived a full build on my

Re: Regarding pledge system call bit value for a non-pledged process

On Sun, Feb 18, 2018 at 09:19:12PM +0530, Neeraj Pal wrote: > yeah, but I am asking about pledge_xbit (pledge value of any process > in hex). See output: > > process name: pltestnopledge(no pledge)ps_flags: > 101007 kern_exec: 10 pid: 66364 pledge_xbit: 8009588f > >

Re: patterns.c question or possible bug

On Mon, Jan 29, 2018 at 11:23:18PM -0600, Edgar Pettijohn wrote: > I'm trying to use patterns.c for some pattern matching. The manual mentions > captures using "()" around what you want to capture. I don't see how to get > at the data though. Here is a sample program. > > #include > #include

Re: malloc optimizations wrt junking and freezero

On Sun, Jan 21, 2018 at 11:50:24AM +0100, Otto Moerbeek wrote: > Hi, > > chunk pages do not need to be junked, all allocated chunks are already > junked on free. Same hold for a few error paths. > > Also, for freezero(), only clear the size as reqeusted instead of the

Re: After 6.1amd64 -> 6.2amd64 upgrade namecoind malloc(): free(): error

On Tue, Jan 23, 2018 at 08:12:49PM +0300, Denis wrote: > Running namecoind 13.2 for about two years. OpenBSD 6.1amd64 is the last > version which supports it. > > On 6.2 I stuck with malloc() hardening. With no any malloc.conf options > I have these errors: > > namecoind (4563) malloc():bogus

malloc optimizations wrt junking and freezero

Hi, chunk pages do not need to be junked, all allocated chunks are already junked on free. Same hold for a few error paths. Also, for freezero(), only clear the size as reqeusted instead of the whole allocation. Please review/test, -Otto Index: malloc.c

Re: malloc.c: correlation between random choices

On Thu, Jan 18, 2018 at 12:05:48PM +0100, Otto Moerbeek wrote: > On Thu, Jan 18, 2018 at 10:48:09AM +, kshe wrote: > > > On Thu, 18 Jan 2018 08:54:21 +, Otto Moerbeek wrote: > > > Looking back the rotor thing is ill-convceived indeed. I'm now > > > testing

Re: /etc/rc: fsck -y

On Thu, Jan 18, 2018 at 12:12:39PM +0200, Artturi Alm wrote: > Hi, > > i think i've never answered "n" to fsck, so to me the lack of -y does > mean unnecessary work/boards/VMs left waiting for the F.. > > i would use something like this if it was there: > > diff --git a/etc/rc b/etc/rc > index

Re: malloc.c: correlation between random choices

On Thu, Jan 18, 2018 at 10:48:09AM +, kshe wrote: > On Thu, 18 Jan 2018 08:54:21 +0000, Otto Moerbeek wrote: > > Looking back the rotor thing is ill-convceived indeed. I'm now > > testing the diff below. I still re-use r, because I really think a > > little bit of corr

Re: malloc.c: correlation between random choices

On Wed, Jan 17, 2018 at 06:25:03PM +0100, Otto Moerbeek wrote: > On Wed, Jan 17, 2018 at 01:59:21PM +, kshe wrote: > > > Hi, > > > > In malloc_bytes(), the choice of the chunk_info list to use is > > correlated with that of the offset at which the search for a

Re: request for testing: malloc bitmap scanning

On Sat, Jan 13, 2018 at 03:36:33PM +0100, Otto Moerbeek wrote: > On Sat, Jan 13, 2018 at 11:14:27AM +0100, Otto Moerbeek wrote: > > > On Sat, Jan 13, 2018 at 09:39:35AM +0100, Otto Moerbeek wrote: > > > > > Hi, > > > > > > This diff is based upon

Re: malloc.c: correlation between random choices

On Wed, Jan 17, 2018 at 01:59:21PM +, kshe wrote: > Hi, > > In malloc_bytes(), the choice of the chunk_info list to use is > correlated with that of the offset at which the search for a free chunk > begins, because both use the same random source. This is easy to avoid, > for example by

Re: request for testing: malloc bitmap scanning

On Sat, Jan 13, 2018 at 11:14:27AM +0100, Otto Moerbeek wrote: > On Sat, Jan 13, 2018 at 09:39:35AM +0100, Otto Moerbeek wrote: > > > Hi, > > > > This diff is based upon kshe's diff, but there's one differene: I am > > using the __builtin_ffs instead of f

Re: request for testing: malloc bitmap scanning

On Sat, Jan 13, 2018 at 09:39:35AM +0100, Otto Moerbeek wrote: > Hi, > > This diff is based upon kshe's diff, but there's one differene: I am > using the __builtin_ffs instead of ffs(3). Looking at the assembly > generated by calling ffs(3) produces a function call, while the

request for testing: malloc bitmap scanning

Hi, This diff is based upon kshe's diff, but there's one differene: I am using the __builtin_ffs instead of ffs(3). Looking at the assembly generated by calling ffs(3) produces a function call, while the __builtin_ffs produces just a few machine instructions on all the platforms I've checked.

Re: malloc cleanup and small optimization (step 3)

On Wed, Jan 03, 2018 at 01:56:43PM +0100, Otto Moerbeek wrote: > Hi, > > this is mostly kshe's work, with an additional change on the cache > maintenance by me. > > I did not take the ffs change yet, since I want to measure the impact > separately. no feedback :-(

Re: typecast to int in awk lshift function.

On Sat, Jan 06, 2018 at 09:00:07AM +, Prabhu Gurumurthy wrote: > On my 6.2 OpenBSD > > europa: [/usr/src/usr.bin/awk] > [1270]>> uname -a > OpenBSD europa.undisclosed.noname 6.2 GENERIC.MP#134 amd64 > > europa: [/usr/src/usr.bin/awk] > [1271]>> echo "172" | awk '{ print lshift($0, 24); }' >

malloc cleanup and small optimization (step 3)

Hi, this is mostly kshe's work, with an additional change on the cache maintenance by me. I did not take the ffs change yet, since I want to measure the impact separately. -Otto Index: malloc.c === RCS file:

Re: malloc cleanup and small optimization (step 2)

On Sat, Dec 30, 2017 at 12:11:50PM -0500, Daniel Micay wrote: > On 30 December 2017 at 06:44, Otto Moerbeek <o...@drijf.net> wrote: > > On Sat, Dec 30, 2017 at 06:53:44AM +, kshe wrote: > > > >> Hi, > >> > >> Looking at this diff and the previo

Re: malloc cleanup and small optimization (step 2)

On Wed, Dec 27, 2017 at 03:20:06PM +0100, Otto Moerbeek wrote: > Hi, > > second step: only init chunk_info on creation. When it is recycled all > values already have proper values to start using it again, e.g. the > free bitmap already has all slots marked free. Plus some m

Re: malloc cleanup and small optimization (step 2)

On Sat, Dec 30, 2017 at 06:53:44AM +, kshe wrote: > Hi, > > Looking at this diff and the previous one, I found some more possible > cleanups for malloc.c (the patch below is to be applied after both of > them, even if the second one has not been committed yet): > > 1. In malloc_bytes(),

Re: malloc.conf.5: minor correction

On Sat, Dec 30, 2017 at 06:16:44AM +, kshe wrote: > Hi, > > The `F' option no longer disables delayed freeing. > > Also, I think documenting implementation details like the exact value > of the junk bytes is not very useful. When you are debugging, it is good to see if a buffer is filled

malloc cleanup and small optimization (step 2)

Hi, second step: only init chunk_info on creation. When it is recycled all values already have proper values to start using it again, e.g. the free bitmap already has all slots marked free. Plus some moving of code to get a better grouping of related functions. -Otto Index: malloc.c

Re: malloc cleanup and small optimizations

On Tue, Dec 26, 2017 at 10:24:01AM +0200, Lari Rasku wrote: > Been running a base linked against this on amd64 since the 24th. > No new problems observed. If there's anything specific I can test > do tell. Thanks for testing. I've committed this. Soon a followup will come. -Otto

Re: mktemp: Clarify error message

On Tue, Dec 26, 2017 at 12:31:02AM +0100, Klemens Nanni wrote: > On Mon, Dec 25, 2017 at 03:57:00PM -0700, Theo de Raadt wrote: > > I think this is a silly solution, and the documentation is clear > > enough. > The manual page certainly is clear enough but the current error message > is logically

Re: malloc cleanup and small optimizations

On Sat, Dec 23, 2017 at 03:39:53PM +0100, Otto Moerbeek wrote: > Hi, > > Largely cleanup and small optimizations: > > - remove over-initializaition of chunks: canary is set only once, > other fields only as-needed. > - remember position of last free bit in chunk_

malloc cleanup and small optimizations

Hi, Largely cleanup and small optimizations: - remove over-initializaition of chunks: canary is set only once, other fields only as-needed. - remember position of last free bit in chunk_info, so we can start at the proper spot the next time. To be able to do this a field was added to chunk_info.

Re: dc: strdup -> bstrdup

On Wed, Dec 06, 2017 at 02:47:13PM +0100, Sebastian Benoit wrote: > Michael W. Bombardieri(m...@ii.net) on 2017.12.06 16:58:27 +0800: > > Hello, > > > > Mostly dc(1) uses its own bstrdup() which exits on error. > > It can be used in two more places. > > i like to read > > if ((a = strdup(b))

Re: dc: strdup -> bstrdup

On Wed, Dec 06, 2017 at 04:58:27PM +0800, Michael W. Bombardieri wrote: > Hello, > > Mostly dc(1) uses its own bstrdup() which exits on error. > It can be used in two more places. > > - Michael Committed, thanks -Otto > > > Index: dc.c >

Re: dc(1); fix 0Z

On Tue, Dec 05, 2017 at 07:51:47AM -0500, Philippe Meunier wrote: > kshe wrote: > >If the number `002' is said to have only one digit because the zeros in > [...] > >the integer logarithm, thus being nothing but arbitrary, and as such of > >little practical value. > > Yes, yes, but "number of

Re: dc(1); fix 0Z

On Sun, Dec 03, 2017 at 07:25:15AM -0500, Philippe Meunier wrote: > kshe wrote: > >Also, the manual defines the length of a number as its number of digits, > >so perhaps it should be precised that zero is considered to have no > >digits, which might not be obvious to everyone. > > Am I the only

Re: dc(1); fix 0Z

On Sat, Dec 02, 2017 at 10:38:00AM +, kshe wrote: > On Sat, 02 Dec 2017 07:50:35 +0000, Otto Moerbeek wrote: > > Spotted while working on kshe's diff. > > > > Makes Z0p work the same as both gnu dc and the orignal dc. > > > > OK? > > I guess you proba

dc(1); fix 0Z

Spotted while working on kshe's diff. Makes Z0p work the same as both gnu dc and the orignal dc. OK? -Otto Index: usr.bin/dc/bcode.c === RCS file: /cvs/src/usr.bin/dc/bcode.c,v retrieving revision 1.57 diff -u -p -r1.57

Re: dc(1): floor(log_10(x)) should not cost more than O(log(log(x)))

On Thu, Nov 30, 2017 at 01:10:33PM +, kshe wrote: > On Thu, 30 Nov 2017 07:22:42 +0000, Otto Moerbeek wrote: > > On Sun, Nov 26, 2017 at 07:40:03PM +, kshe wrote: > > > Hi, > > > > > > The `Z' command can be a handy shortcut for computing lo

Re: dc(1): floor(log_10(x)) should not cost more than O(log(log(x)))

On Sun, Nov 26, 2017 at 07:40:03PM +, kshe wrote: > Hi, > > The `Z' command can be a handy shortcut for computing logarithms; as > such, for example, it is the basis of the implementation of bc(1)'s `l' > function. However, the algorithm currently used in count_digits() is > too naive to be

Re: [patch] upon install of new operating system version, do not set root password to empty string

On Tue, Nov 28, 2017 at 06:59:06PM -0500, Ian Sutton wrote: > This is a highly theoretical and experimental mitigation which stops the > root password on newly upgraded/installed systems from being an empty > string. The thinking is that by not shipping an operating system with a > known root

Re: fuse: vfs create does not map 1:1 to fuse create

On Tue, Nov 28, 2017 at 10:59:07PM +0800, Helg wrote: One small comment from me: > /* already open i think all is ok */ > if (ip->fufh[fufh_type].fh_type != FUFH_INVALID) > return (0); > > + /* > + * The file has already been created and/or truncated so FUSE

Re: dc(1) mishandles fractional input in bases other than 10

On Sun, Nov 26, 2017 at 07:51:13PM +, kshe wrote: > Hi, > > The following behaviour seems unacceptable to me. > > $ dc -e '16dio .C .C0 f' > .C0 > .B > > $ dc -e '8dio .3 .30 .300 f' > .3000 > .275 > .23 > > This bug affects all bases other than

Re: dc(1): dead store

On Sun, Nov 26, 2017 at 07:43:22PM +, kshe wrote: > Hi, > > This assignment is useless. > > Index: bcode.c > === > RCS file: /cvs/src/usr.bin/dc/bcode.c,v > retrieving revision 1.51 > diff -u -p -r1.51 bcode.c > --- bcode.c

<    1   2   3   4   5   6   7   8   9   >