Re: quiz: Fix multi-line questions (trailing newline)

2021-03-10 Thread Christian Weisgerber
Todd C. Miller: > I don't think your use of qlen is safe since it is initialized > to zero. Specifically, it looks like "qp->q_text[qlen - 1]" > would be an out of bounds read. Should qlen be initialized > to strlen(qp->q_text) if qp->q_text != NULL? Right. Next iteration: Index: quiz.c

Re: quiz: Fix multi-line questions (trailing newline)

2021-03-09 Thread Christian Weisgerber
Alex Karle: > Looking deeper, there is a bug in quiz(6) for datfiles with multi-line > answers. > > Specifically, the following quiz.db line: > > foo:\ > bar > > Is parsed into "foo:bar\n", which made it impossible to get right (since > the comparison was expecting a newline).

Re: ftp: make use of getline(3)

2021-02-14 Thread Christian Weisgerber
Christian Weisgerber: > > Make use of getline(3) in ftp(1). > > > > Replace fparseln(3) with getline(3). This removes the only use > > of libutil.a(fparseln.o) from the ramdisk. > > Replace a complicated fgetln(3) idiom with the much simpler getline(3). >

Re: ftp: make use of getline(3)

2021-02-06 Thread Christian Weisgerber
Christian Weisgerber: > Make use of getline(3) in ftp(1). > > Replace fparseln(3) with getline(3). This removes the only use > of libutil.a(fparseln.o) from the ramdisk. > Replace a complicated fgetln(3) idiom with the much simpler getline(3). New diff that fixes a bug I intro

disklabel: make use of getline(3)

2021-01-31 Thread Christian Weisgerber
Replace fgetln(3) with getline(3). Since getline() returns a C string, we don't need to carry around the length separately. OK? Index: sbin/disklabel/editor.c === RCS file: /cvs/src/sbin/disklabel/editor.c,v retrieving revision

fdisk: make use of getline(3)

2021-01-30 Thread Christian Weisgerber
Replace fgetln(3) with getline(3). OK? Index: sbin/fdisk/misc.c === RCS file: /cvs/src/sbin/fdisk/misc.c,v retrieving revision 1.63 diff -u -p -r1.63 misc.c --- sbin/fdisk/misc.c 3 Jul 2019 03:24:01 - 1.63 +++

disklabel: pointer deref fix

2021-01-29 Thread Christian Weisgerber
Fix a pointer dereference in disklabel(8). This looks like somebody wrote *s[0] in place of (*s)[0]. Which in this case happens to be equivalent, but it still looks wrong. OK? Index: sbin/disklabel/editor.c === RCS file:

sed: make use of getline(3)

2021-01-29 Thread Christian Weisgerber
Replace fgetln(3) with getline(3) in sed. The mf_fgets() part is from Johann Oskarsson for Illumos/FreeBSD. Passes our sed regression tests. OK? Index: usr.bin/sed/main.c === RCS file: /cvs/src/usr.bin/sed/main.c,v retrieving

Re: ftp: make use of getline(3)

2021-01-29 Thread Christian Weisgerber
Hiltjo Posthuma: > > @@ -75,19 +74,8 @@ cookie_load(void) > > if (fp == NULL) > > err(1, "cannot open cookie file %s", cookiefile); > > date = time(NULL); > > - lbuf = NULL; > > - while ((line = fgetln(fp, )) != NULL) { > > - if (line[len - 1] == '\n') { > > -

ftp: make use of getline(3)

2021-01-29 Thread Christian Weisgerber
Make use of getline(3) in ftp(1). Replace fparseln(3) with getline(3). This removes the only use of libutil.a(fparseln.o) from the ramdisk. Replace a complicated fgetln(3) idiom with the much simpler getline(3). OK? Index: distrib/special/ftp/Makefile

Re: getopt.3 bugs section

2021-01-09 Thread Christian Weisgerber
Edgar Pettijohn: > In the BUGS section for the getopt(3) manual it mentions not using > single digits for options. I know spamd uses -4 and -6 there are > probably others. Should they be changed? Or is the manual mistaken? You misunderstand. The manual warns against the use of digits to pass

Re: Rename SIMPLEQ_ to STAILQ_, diff 1/7

2020-12-28 Thread Christian Weisgerber
Denis Fondras: > This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify with > FreeBSD and Linux. > > I added aliases at the end of queue.h to avoid breaking base too much. they > will > be removed as soon as diff 2,3,4,5,6,7 are commited. > > net/sniproxy has a patch to define

Re: Rename SIMPLEQ_ to STAILQ_, diff 1/7

2020-12-26 Thread Christian Weisgerber
Theo de Raadt: > What is lacking in this converstation is the justification. > Why? Providing STAILQ in OpenBSD will simplify porting to OpenBSD. (Reality check: There is one port affected by this.) Switching OpenBSD to STAILQ will simplify porting from OpenBSD. (There are three or four FreeBSD

Re: Rename SIMPLEQ_ to STAILQ_, diff 1/7

2020-12-26 Thread Christian Weisgerber
Denis Fondras: > This diff renames SIMPLEQ_* to STAILQ_* in /usr/src/sys/sys to unify with > FreeBSD and Linux. > > I added aliases at the end of queue.h to avoid breaking base too much. they > will > be removed as soon as diff 2,3,4,5,6,7 are commited. We'll need to run a ports bulk build

libcurses: --enable-const

2020-12-12 Thread Christian Weisgerber
ncurses has a configure option that adds a few more consts to its headers by way of the NCURSES_CONST define. Starting with version 6.0, this has become the default. OpenBSD is still on ncurses 5.7, but FreeBSD and I guess most Linux distributions have moved on. I suggest we also enable the

Re: rpki-client: use strndup instead of malloc + memcpy

2020-12-03 Thread Christian Weisgerber
Claudio Jeker: > In tal_parse() use strndup() to create the tal descr instead of the more > complex malloc, memcpy version. Result is the same but the strndup version > is a lot nicer. Yes, but... > --- tal.c 11 Oct 2020 12:39:25 - 1.22 > +++ tal.c 3 Dec 2020 12:00:25 - >

Re: powerpc lld fix

2020-11-15 Thread Christian Weisgerber
Mark Kettenis: > What would the impact on ports of disabling base-gcc be on powerpc? None. $ cd /usr/ports $ make ARCH=macppc MACHINE_ARCH=powerpc show=CHOSEN_COMPILER |grep -B1 base-gcc $ -- Christian "naddy" Weisgerber na...@mips.inka.de

basename(3) should have non-const arg, says POSIX

2020-10-19 Thread Christian Weisgerber
[Picking this up again after a month:] Our basename(3) and dirname(3) take a const argument: char*basename(const char *); char*dirname(const char *); POSIX says otherwise... char *basename(char *path); char *dirname(char *path); ... and explicitly says the functions may modify

arm64 ddb: decode "udf" instruction

2020-10-19 Thread Christian Weisgerber
This decodes the UDF ("permanently undefined") instruction in ddb's arm64 disassembler. The particular immediate16 format appears to be unique to this instruction. OK? Or don't bother? Index: arch/arm64/arm64/disasm.c === RCS

arm64, armv7: proper illegal instruction

2020-10-19 Thread Christian Weisgerber
Belatedly, ARM has taken a slice of the reserved opcode space and assigned it as a properly defined illegal instruction, udf #imm16. (Armv8 Architecture Reference Manual, edition F.c, section C6.2.335). Clang already knows about it. We really should use this instead of picking something ad-hoc

Non-const basename: usr.bin/cvs

2020-10-16 Thread Christian Weisgerber
Accommodate POSIX basename(3) that takes a non-const parameter and may modify the string buffer. There were only two compiler warnings about discarded const, but there are numerous instances where the code assumes non-POSIX semantics for basename() and dirname(). Given that there is at least a

Non-const basename: usr.bin/ftp

2020-10-15 Thread Christian Weisgerber
Accommodate POSIX basename(3) that takes a non-const parameter and may modify the string buffer. I've tried to follow the conventions of the existing code. ok? Index: usr.bin/ftp/fetch.c === RCS file: /cvs/src/usr.bin/ftp/fetch.c,v

Non-const basename: usr.sbin/vmd, usr.sbin/vmctl

2020-10-14 Thread Christian Weisgerber
Accommodate POSIX basename(3) that takes a non-const parameter and may in fact modify the string buffer. The file is built by vmd and vmctl. I'm uncertain if we want a truncation check here. Both in vmd and vmctl, the path has been validated by a previous open(), but given the code complexity,

Non-const basename: usr.bin/rcs

2020-10-14 Thread Christian Weisgerber
Accommodate POSIX basename(3) that takes a non-const parameter and may in fact modify the string buffer. ok? Index: usr.bin/rcs/rlog.c === RCS file: /cvs/src/usr.bin/rcs/rlog.c,v retrieving revision 1.74 diff -u -p -r1.74 rlog.c ---

Non-const basename: sbin/pfctl

2020-10-13 Thread Christian Weisgerber
Accommodate a basename(3) that takes a non-const parameter and may in fact modify the string buffer. The length of anchor has already been checked in main(). ok? Index: sbin/pfctl/pfctl.c === RCS file: /cvs/src/sbin/pfctl/pfctl.c,v

net/pfvar.h: MAXPATHLEN -> PATH_MAX

2020-10-13 Thread Christian Weisgerber
In revision 1.407 of , deraadt@ replaced MAXPATHLEN with PATH_MAX so userland wouldn't have to pull in . In 1.466, sashan@ accidentally slipped one MAXPATHLEN back in, because its use is ubiquitous on the kernel side of pf. Switch this over to PATH_MAX again. pfctl(8) doesn't actually use this,

Non-const basename: bin/chio

2020-10-13 Thread Christian Weisgerber
As far as I understand, the basename() here is specifically intended to skip a leading "/dev/". So how about doing this expressly? Do we want to use _PATH_DEV or "/dev/"? There's a "/dev/rst%d" a few lines outside of the diff context... Index: bin/chio/parse.y

Non-const basename: usr.sbin/hotplugd

2020-10-13 Thread Christian Weisgerber
Accommodate a basename(3) that takes a non-const parameter and may in fact modify the string buffer. Between access(file, ...) and execl(file, ...), no check for truncation should be necessary. ok? Index: usr.sbin/hotplugd/hotplugd.c

Non-const basename: libkvm

2020-10-13 Thread Christian Weisgerber
Accommodate a basename(3) that takes a non-const parameter and may in fact modify the string buffer. Note that strlen(uf) >= PATH_MAX is already checked by the caller in _kvm_open(). ok? Index: lib/libkvm/kvm.c === RCS file:

Re: Non-const basename: usr.bin/sed

2020-10-11 Thread Christian Weisgerber
Martijn van Duren: > Wouldn't the following diff be a little simpler? Yes, it would. Should dirbuf be static like oldfname and tmpfname? Index: main.c === RCS file: /cvs/src/usr.bin/sed/main.c,v retrieving revision 1.40 diff -u

Re: WANTLIB problems and possible solution: the libset design

2020-10-11 Thread Christian Weisgerber
Marc Espie: > The new design: > > The idea behind "libset" is to be able to specify a "set" of wantlib that > corresponds to our package, AND to just write WANTLIB wrt that libset for > that specific set of libraries. I'm struggling to understand whether this libset records the libraries a port

Non-const basename: usr.bin/compress

2020-10-10 Thread Christian Weisgerber
Accommodate POSIX basename(3) that takes a non-const parameter and may in fact modify the string buffer. Following martijn@'s comment for the sed diff, we don't need to check for truncation because the "in" path has already been validated by a preceding open(2). ok? Index:

Non-const basename: usr.bin/sed

2020-10-10 Thread Christian Weisgerber
Changing basename(3) and dirname(3) to the POSIX-mandated non-const parameters produces this warnings when compiling sed(1): /usr/src/usr.bin/sed/main.c:401:16: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qua lifiers]

Non-const basename: usr.bin/patch

2020-10-10 Thread Christian Weisgerber
Changing basename(3) and dirname(3) to the POSIX-mandated non-const parameters produces these warnings when compiling patch(1): /usr/src/usr.bin/patch/backupfile.c:61:34: warning: passing 'const char *' to pa rameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-disca

Re: ssh-keygen: generate ed25519 keys by default

2020-10-08 Thread Christian Weisgerber
On 2020-10-08, Eldritch wrote: > With the recent change to prefer ed25519 keys on the server side [1] > (unless I misunderstood what the change does), I think generating This only changed the client's order of preference for the various server key types. If a server doesn't offer an Ed25519

Re: basename(3) should have non-const arg, says POSIX

2020-09-12 Thread Christian Weisgerber
Todd C. Miller: > This is probably the right thing to do but we should fix the warnings > it generates. In this new world order, passing a const char * to > basename() or dirname() is unsafe. FWIW, here's the list: /usr/src/lib/libkvm/kvm.c:684:16: warning: passing 'const char *' to parameter

basename(3) should have non-const arg, says POSIX

2020-09-12 Thread Christian Weisgerber
Our basename(3) and dirname(3) take a const argument: char*basename(const char *); char*dirname(const char *); POSIX says otherwise... char *basename(char *path); char *dirname(char *path); ... and explicitly says the functions may modify the input string. Our functions were

Format string check for dprintf(3)

2020-09-10 Thread Christian Weisgerber
Add format string checking annotations for dprintf(3) and vdprintf(3). This was apparently forgotten when the functions were added. It is required so the compiler can warn t.c:25:25: warning: format string is not a string literal (potentially insecure) [-Wformat-security]

Re: timekeep: fixing large skews on amd64 with RDTSCP

2020-08-23 Thread Christian Weisgerber
Scott Cheloha: > This "it might slow down the network stack" thing keeps coming up, and > yet nobody can point to (a) who expressed this concern or (b) what the > penalty is in practice. It was kettenis@ who simply raised the question and asked for comments from the network people. I think we

Re: man find -exec -- a little bit more hand-holding

2020-08-14 Thread Christian Weisgerber
On 2020-08-14, Jason McIntyre wrote: > - i cannot work out what is with the \! examples. i know we try to make > entries work for both csh and sh style shells, but stuff like this > works without escaping: > > $ find . ! -type f Going through the CVS and SCCS history, I see that the

mountd: Avoid reading one byte before buffer

2020-08-06 Thread Christian Weisgerber
>From CheriBSD, via FreeBSD: | Avoid reading one byte before the path buffer. | | This happens when there's only one component (e.g. "/foo"). This | (mostly-harmless) bug has been present since June 1990 when it was | commited to mountd.c SCCS version 5.9. | | Note: the bug is on the second

Re: timekeep: fixing large skews on amd64 with RDTSCP

2020-07-27 Thread Christian Weisgerber
Scott Cheloha: > --- lib/libc/arch/amd64/gen/usertc.c 8 Jul 2020 09:17:48 - 1.2 > +++ lib/libc/arch/amd64/gen/usertc.c 25 Jul 2020 17:50:38 - > @@ -21,9 +21,12 @@ > static inline u_int > rdtsc(void) > { > - uint32_t hi, lo; > - asm volatile("rdtsc" : "=a"(lo),

Re: timekeep: fixing large skews on amd64 with RDTSCP

2020-07-16 Thread Christian Weisgerber
Scott Cheloha: > Can we add the missing LFENCE instructions to userspace and the > kernel? And can we excise the upper 32 bits? > + uint32_t lo; > + > + asm volatile("lfence"); > + asm volatile("rdtsc" : "=a"(lo)); That's wrong. rtdsc will clobber %rdx, whether you use that value

Re: armv7: tweak timercounter mask

2020-07-12 Thread Christian Weisgerber
Mark Kettenis: > > There is the strong suspicion that the 0x7fff mask in the various > > armv7 timecounters was simply copied from powerpc, and that these really > > are full 32-bit counters. > > > > I wanted to verify this from the data sheets, but I'm insufficiently > > familiar with the

Re: powerpc(64): tweak timecounter mask

2020-07-12 Thread Christian Weisgerber
Mark Kettenis: > > Date: Sun, 12 Jul 2020 18:12:39 +0200 > > From: Christian Weisgerber > > > > The PowerPC/Power ISA Time Base is a 64-bit register. We can use > > the full lower 32 bits. > > > > OK? > > Sure, but this needs to be coordinated

armv7: tweak timercounter mask

2020-07-12 Thread Christian Weisgerber
There is the strong suspicion that the 0x7fff mask in the various armv7 timecounters was simply copied from powerpc, and that these really are full 32-bit counters. I wanted to verify this from the data sheets, but I'm insufficiently familiar with the ARM ecosystem to locate those. Back in

Re: powerpc(64): tweak timecounter mask

2020-07-12 Thread Christian Weisgerber
Christian Weisgerber: > - tb_get_timecount, NULL, 0x7fff, 0, "tb", 0, NULL, 0 > + tb_get_timecount, NULL, 0x, 0, "tb", 0, NULL, 0 PS: Do we prefer ~0u over 0x? -- Christian "naddy" Weisgerber na...@mips.inka.de

powerpc(64): tweak timecounter mask

2020-07-12 Thread Christian Weisgerber
The PowerPC/Power ISA Time Base is a 64-bit register. We can use the full lower 32 bits. OK? Index: arch/macppc/macppc/clock.c === RCS file: /cvs/src/sys/arch/macppc/macppc/clock.c,v retrieving revision 1.44 diff -u -p -r1.44

Re: arm64 usertc

2020-07-11 Thread Christian Weisgerber
Mark Kettenis: > Nevertheless, here is a different take on the problem. Since the > timecounter only uses the low 32 bits we don't need the double read. > This version also changes the timecounter mask from 0x7fff to > 0x. That must be ok, since the counter has 64 bits and we are >

Re: userland clock_gettime proof of concept

2020-07-08 Thread Christian Weisgerber
On 2020-06-26, George Koehler wrote: > Here's macppc again. My macppc isn't using your newest diff but does > now need to define TC_TB in . Crucial question: How confident are we that TB is in sync on multiprocessor machines? -- Christian "naddy" Weisgerber

Re: user tc for alpha

2020-07-08 Thread Christian Weisgerber
Paul Irofti: > > Userland gettime support for alpha. > > Alas, completely untested since I don't have access to that arch. > > Never had an alpha. Reads OK to me (if you make the function static like > kettenis@ said). For the archives, here's a version that looks like kettenis@'s style.

Re: user tc for alpha

2020-07-07 Thread Christian Weisgerber
Mark Kettenis: > > --- lib/libc/arch/alpha/gen/usertc.c6 Jul 2020 13:33:05 - > > 1.1 > > +++ lib/libc/arch/alpha/gen/usertc.c7 Jul 2020 20:40:37 - > > +int > > +tc_get_timecount(struct timekeep *tk, u_int *tc) > > Need to make this function static to avoid

user tc for alpha

2020-07-07 Thread Christian Weisgerber
Userland gettime support for alpha. Alas, completely untested since I don't have access to that arch. Index: lib/libc/arch/alpha/gen/usertc.c === RCS file: /cvs/src/lib/libc/arch/alpha/gen/usertc.c,v retrieving revision 1.1 diff -u

Re: userland clock_gettime proof of concept

2020-07-03 Thread Christian Weisgerber
On 2020-07-03, Scott Cheloha wrote: > Are we doing powerpc, arm64, and sparc64 separately? hppa can de done as well, but somebody with access to a machine needs to investigate/ensure that the S bit in the processor status register is appropriately set to allow userland access to the Interval

Re: userland clock_gettime proof of concept

2020-07-03 Thread Christian Weisgerber
On 2020-07-03, Mark Kettenis wrote: > Are the issue that naddy@ saw solved? Yes, they were understood and fixed. I'll defer to you and Scott regarding the TSC synchronization issues; aside from that I'm okaying the diff. -- Christian "naddy" Weisgerber

Re: powerpc64: 64-bit-ize memmove.S

2020-06-26 Thread Christian Weisgerber
Christian Weisgerber: > Well, I suggested it, so here's my attempt to switch powerpc64's > libc memmove.S over to 64 bits: Actually, on second thought: That function simply copies as many (double)words plus a tail of bytes as the length argument specifies. Neither source nor desti

powerpc64: 64-bit-ize memmove.S

2020-06-26 Thread Christian Weisgerber
Well, I suggested it, so here's my attempt to switch powerpc64's libc memmove.S over to 64 bits: * Treat length parameter as 64 bits (size_t) instead of 32 (u_int). * Set up the main loop to copy 64-bit doublewords instead of 32-bit words. This definitely needs double and triple checking.

Re: ffs(3): libc arch versions, regress

2020-06-25 Thread Christian Weisgerber
20:31:19 - @@ -0,0 +1,18 @@ +/* $OpenBSD$ */ +/* + * Written by Christian Weisgerber . + * Public domain. + */ + +#include "DEFS.h" + +ENTRY(ffs) + RETGUARD_SETUP(ffs, x15) + rbitw1, w0 + clz w1, w1 + cmp w0, wzr + csinc w0, w

RIP, freedb (cddb service)

2020-06-24 Thread Christian Weisgerber
The freedb.org CD track database is dead. Its shutdown had already been announced for March, and it finally disappeared. gnudb.org, whoever they are, offers the last working alternative that still supports the CDDB protocol. Actually, the port was dead yesterday, but they fixed it today. I

Re: userland clock_gettime proof of concept

2020-06-22 Thread Christian Weisgerber
Christian Weisgerber: > If I move > > vaddr_t ps_timekeep;/* User pointer to timekeep */ > > up into the zeroed area, I get a properly randomized _timekeep in > userland. Also note that exec_sigcode_map() has this pr->ps_si

Re: userland clock_gettime proof of concept

2020-06-22 Thread Christian Weisgerber
Paul Irofti: > 683 /* map the process's timekeep page */ > 684 if (exec_timekeep_map(pr)) > 685 goto free_pack_abort; > 686 /* setup new registers and do misc. setup. */ > 687 if (pack.ep_emul->e_fixup != NULL) { > 688 if

Re: userland clock_gettime proof of concept

2020-06-21 Thread Christian Weisgerber
Christian Weisgerber: > I tweaked the patch locally to make _timekeep a visible global > symbol in libc. > > Printing its value has revealed two issues: > > * The timekeep page is mapped to the same address for every process. > It changes across reboots, but once running,

Re: userland clock_gettime proof of concept

2020-06-21 Thread Christian Weisgerber
Paul Irofti: [Unrelated, just to mark where we're at] > Right. Just reproduced it here. This moves the check at the top so that > each CPU checks its own skew and disables tc_user if necessary. I tweaked the patch locally to make _timekeep a visible global symbol in libc. Printing its value has

Re: userland clock_gettime proof of concept

2020-06-21 Thread Christian Weisgerber
Paul Irofti: > > b) Revert _timekeep init (breaks naddy@'s machine) > > Robert helped properly track down this issue to a silly null-ref. If that was indeed the problem... > --- lib/libc/dlfcn/init.c > +++ lib/libc/dlfcn/init.c > @@ -105,6 +107,14 @@ _libc_preinit(int argc, char **argv, char

Re: Retire

2020-06-21 Thread Christian Weisgerber
On 2020-06-20, Christian Weisgerber wrote: >> Well... they something in ports might still look at them in >> >> >> Can someone from ports speak about this? > > I have started an amd64 bulk build without . There were no build failures attributable to t

Re: userland clock_gettime proof of concept

2020-06-21 Thread Christian Weisgerber
Paul Irofti: > Can't test right now, but if you enable the TSC_DEBUG in cpu.c or if you > put a printf in the CPU_INFO_FOREACH you will probably see the correct > skew values. It's worse: CPU_INFO_FOREACH() only sees cpu0. The others aren't attached yet. -- Christian "naddy" Weisgerber

Re: userland clock_gettime proof of concept

2020-06-21 Thread Christian Weisgerber
Paul Irofti: > This also handles negative skew values that my prevoius diff did not. > --- sys/arch/amd64/amd64/tsc.c > +++ sys/arch/amd64/amd64/tsc.c > @@ -216,6 +217,8 @@ tsc_get_timecount(struct timecounter *tc) > void > tsc_timecounter_init(struct cpu_info *ci, uint64_t cpufreq) > { > +

Re: userland clock_gettime proof of concept

2020-06-20 Thread Christian Weisgerber
On 2020-06-20, Christian Weisgerber wrote: > I can't get this revision of the diff to work on amd64: > * patch source > * build and install kernel, reboot > * make build > * reboot -> "Process (pid 1) got signal 11" > > I'm at a loss. As part of the "

Re: userland clock_gettime proof of concept

2020-06-20 Thread Christian Weisgerber
On 2020-06-19, Paul Irofti wrote: > I have addressed your comments bellow, except for the CPU skew one. That > code disables TSC for all CPUs, not just for PRIMARY. Would you like to > walk and add code for every CPU to check the drift and then disable the > TSC? It seems a little too much... >

Re: Retire

2020-06-20 Thread Christian Weisgerber
On 2020-06-19, "Theo de Raadt" wrote: > Well... they something in ports might still look at them in > > Can someone from ports speak about this? I have started an amd64 bulk build without . -- Christian "naddy" Weisgerber na...@mips.inka.de

Re: userland clock_gettime proof of concept

2020-06-19 Thread Christian Weisgerber
On 2020-06-19, Mark Kettenis wrote: > I'm talking about *skew*, not drift. If there is a significant drift > you already knock out the TSC. > > What's needed is: > > 1. A bit of research of what an acceptable skew is. My hypothesis is >that on many machines with a single socket the TSCs

Re: improve pkg_add bandwidth usage with some mirrors

2020-06-19 Thread Christian Weisgerber
On 2020-06-18, Marc Espie wrote: > What pkg_add does internally is a pipeline: > > ftp | signify|internal gunzip > > closing the end file handle should kill the whole chain. > So I need to figure out where it goes wrong, what's the > part that doesn't die "instantly". That's ftp(1). Our SSL

Re: userland clock_gettime proof of concept

2020-06-14 Thread Christian Weisgerber
George Koehler: > --- lib/libc/arch/powerpc/gen/usertc.c.before Sat Jun 13 21:28:50 2020 > +++ lib/libc/arch/powerpc/gen/usertc.cSat Jun 13 21:38:52 2020 > @@ -18,4 +18,19 @@ > #include > #include > > -int (*const _tc_get_timecount)(struct timekeep *, uint64_t *) = NULL; > +int >

Re: symmetric toeplitz hashing

2020-06-13 Thread Christian Weisgerber
On 2020-06-13, Theo Buehler wrote: > Others have pointed out off-list that one can use __builtin_popcount(), > but __builtin_parity() is exactly what I want. Is it available on all > architectures? The standard implementation will be perfectly fine, no need to resort to magic compiler

cpu_rnd_messybits() for hppa

2020-06-12 Thread Christian Weisgerber
Here's a cpu_rnd_messybits() for hppa. This just steals from itmr_get_timecount(). If we want to use the mfctl() macro, we need to include into cpu.h. I don't know if we want that, so I went with the explicit asm() instead. Completely untested. Index: sys/arch/hppa/hppa/machdep.c

Re: ffs(3): libc arch versions, regress

2020-06-12 Thread Christian Weisgerber
Christian Weisgerber: > This adds the optimized ffs(3) versions on aarch64 and powerpc to > libc, for completeness' sake. > > Also add a brief regression test. > > OK? Index: lib/libc/arch/aarch64/string/Makefile.inc ==

Re: userland clock_gettime proof of concept

2020-06-11 Thread Christian Weisgerber
Theo de Raadt: > The diff is growing complexity to support a future which wouldn't > exist if attempts at *supporting all* architectures received priority. Adding support for more archs is very simple, since you just need to copy the corresponding get_timecounter function from the kernel.

Re: userland clock_gettime proof of concept

2020-06-11 Thread Christian Weisgerber
Paul Irofti: > > Paul, that tk_nclocks addition isn't useful. You need to do the > > bounds checking against the number of clocks you have implemented in > > libc. How many clocks the kernel has implemented doesn't matter. > > What you are saying is that we could be in a situation where the

Re: userland clock_gettime proof of concept

2020-06-11 Thread Christian Weisgerber
Paul Irofti: [lib/libc/arch/*/gen/usertc.c] > +int (*const _tc_get_timecount)(struct timekeep *, uint64_t *) = NULL; [lib/libc/sys/microtime.c] > +static inline int > +tc_delta(struct timekeep *tk, u_int *delta) > +{ > + uint64_t tc; > + if (delta == NULL || _tc_get_timecount(tk, ))

Re: userland clock_gettime proof of concept

2020-06-11 Thread Christian Weisgerber
Paul Irofti: > > Additionally, it changes struct timekeep in an incompatible way. ;-) > > A userland built before the addition of tk_nclocks is very unhappy > > with a kernel built afterwards. > > I have not seen this problem and have not built a snapshot to update or go > back. What do you mean

Re: userland clock_gettime proof of concept

2020-06-11 Thread Christian Weisgerber
Christian Weisgerber: > Should we already bump major while the diff matures? Oh, we can't quite bump yet. tk_major und tk_minor are only set in exec_timekeep_map(), but aren't checked anywhere. + timekeep->tk_major = 0; + timekeep->tk_minor = 0; Those

Re: userland clock_gettime proof of concept

2020-06-10 Thread Christian Weisgerber
Paul Irofti: > This iteration of the diff adds bounds checking for tk_user and moves > the usertc.c stub to every arch in libc as recommanded by deraadt@. > It also fixes a gettimeofday issue reported by cheloha@ and tb@. Additionally, it changes struct timekeep in an incompatible way. ;-) A

Re: userland clock_gettime proof of concept

2020-06-10 Thread Christian Weisgerber
Paul Irofti: > > This iteration of the diff adds bounds checking for tk_user and moves > > the usertc.c stub to every arch in libc as recommanded by deraadt@. > > It also fixes a gettimeofday issue reported by cheloha@ and tb@. > > Forgot to add armv7 tk_nclock entries. Noticed by benno@,

Re: libkern: ffs() for arm64, powerpc, powerpc64

2020-06-10 Thread Christian Weisgerber
/libkern/arch/arm64/ffs.S diff -N lib/libkern/arch/arm64/ffs.S --- /dev/null 1 Jan 1970 00:00:00 - +++ lib/libkern/arch/arm64/ffs.S10 Jun 2020 17:38:50 - @@ -0,0 +1,17 @@ +/* $OpenBSD$ */ +/* + * Written by Christian Weisgerber . + * Public domain. + */ + +#include + +ENTRY(ffs

Re: libkern: ffs() for arm64, powerpc, powerpc64

2020-06-09 Thread Christian Weisgerber
Mark Kettenis: > Unfortunately that doesn't quite work. At least in my build it > doesn't pick up .c files in the linker/arch directories. > > > Index: lib/libkern/arch/arm64/ffs.c I was certain I had checked this, but indeed it doesn't work. The Makefile rules are generated from

Re: libkern: ffs() for arm64, powerpc, powerpc64

2020-06-09 Thread Christian Weisgerber
On 2020-06-09, Christian Weisgerber wrote: > Here are optimized ffs(3) implementations for > * arm64 (superseding the earlier ffs.S) > * powerpc > * powerpc64 > +int ffs(int x) Oops, I'm going to change that to int ffs(int x) before commit. -- Christian &qu

ffs(3): libc arch versions, regress

2020-06-09 Thread Christian Weisgerber
-N lib/libc/arch/aarch64/string/ffs.c --- /dev/null 1 Jan 1970 00:00:00 - +++ lib/libc/arch/aarch64/string/ffs.c 9 Jun 2020 19:54:21 - @@ -0,0 +1,15 @@ +/* $OpenBSD$ */ +/* + * Written by Christian Weisgerber . + * Public domain. + */ + +#include + +int +ffs(int x) +{ + x = x

Re: libkern: ffs() for arm64

2020-06-08 Thread Christian Weisgerber
On 2020-06-08, Christian Weisgerber wrote: > More archs to come... Style question: Since this mostly comes down to embedding a single special instruction in between normal C operations, I wonder whether I should just do .c with asm() instead of .S, and leave all the boilerplate to the compi

libkern: ffs() for arm64

2020-06-08 Thread Christian Weisgerber
$ */ +/* + * Written by Christian Weisgerber . + * Public domain. + */ + +#include + +ENTRY(ffs) + RETGUARD_SETUP(ffs, x15) + rbitw1, w0 + clz w1, w1 + cmp w0, #0 + csinc w0, wzr, w1, eq + RETGUARD_CHECK(ffs, x15) + ret +END(ffs) -- Christian

Re: powerpc64: ldbrx/stdbrx for endian.h?

2020-06-08 Thread Christian Weisgerber
On 2020-06-08, Christian Weisgerber wrote: >> Did they also happen to add opcodes for doing swaps in registers? > > No. > (I haven't looked at the vector instructions yet.) PS: There's a vector permutate instruction, but AFAICT there is no way to move data between general pur

Re: powerpc64: ldbrx/stdbrx for endian.h?

2020-06-08 Thread Christian Weisgerber
David Gwynne: > > Starting with POWER7 (Power ISA v.2.06), there are also corresponding > > 64-bit instructions. Do we want to use those on powerpc64? Or do > > we want to keep compatibility with older processors? > > I'm ok with using the instructions. I can't think of what benefit compat in

powerpc64: ldbrx/stdbrx for endian.h?

2020-06-08 Thread Christian Weisgerber
powerpc has byte-swapping 16 and 32-bit load/stores and we use those in . Starting with POWER7 (Power ISA v.2.06), there are also corresponding 64-bit instructions. Do we want to use those on powerpc64? Or do we want to keep compatibility with older processors? Index:

Re: cpu_rnd_messybits() for arm64

2020-06-05 Thread Christian Weisgerber
Mark Kettenis: > > Here is a cpu_rnd_messybits() implementation for arm64. > > It reads the virtual counter and xors it with a bit-reversed copy > > of itself. > > > > The virtual counter is used by the only timecounter implementation > > used on arm64, so I assume it is generally available. > >

cpu_rnd_messybits() for arm64

2020-06-05 Thread Christian Weisgerber
Here is a cpu_rnd_messybits() implementation for arm64. It reads the virtual counter and xors it with a bit-reversed copy of itself. The virtual counter is used by the only timecounter implementation used on arm64, so I assume it is generally available. It's a 64-bit counter, which we reduce to

cpu_rnd_messybits() for alpha, powerpc, sparc64

2020-06-04 Thread Christian Weisgerber
Here's a proposal for implementing cpu_rnd_messybits() as a read of the cycle counter on alpha, powerpc, and sparc64. Since I don't have those archs, the diff is not even compile-tested. * alpha: RPCC is a 32-bit counter (in a 64-bit register) * powerpc: TB is a 64-bit counter split into two

Re: userland clock_gettime proof of concept

2020-06-01 Thread Christian Weisgerber
Theo de Raadt: > > Then you still need to check on every call whether the clockid has > > changed (because the kern.timecounter.hardware sysctl was changed) > > and refetch the function pointer in that case. > > Then really, we should remove that sysctl support. > > Because otherwise I don't

Re: Xwindows keymap weirdness

2020-06-01 Thread Christian Weisgerber
Marc Espie: > If I type 'c > > I get a ç in programs like firefox or chrome, BUT I get > ć in xterm ? > > why are things different ? which program is right ? GTK comes with its own compose rules that are occasionally different from the default X11 ones. Personally, I disable GTK's compose

Re: official ports vs DEBUG_PACKAGES

2020-05-29 Thread Christian Weisgerber
Marc Espie: > There are about 3 solutions to that: > - change the bulk machines to /usr/ports/pobj > - change the ports default to /usr/obj/ports I don't think it's reasonable to expect everybody to use the same path here. -- Christian "naddy" Weisgerber

Re: random(4): use arc4random_ctx_buf() for large device reads

2020-05-25 Thread Christian Weisgerber
Sebastien Marie: > > For large reads from /dev/random, use the arc4random_ctx_*() functions > > instead of hand-rolling the same code to set up a temporary ChaCha > > instance. > > Eventually, I would get ride of myctx, initialize lctx to NULL, and use > (lctx == NULL) to replace (myctx == 0).

random(4): use arc4random_ctx_buf() for large device reads

2020-05-24 Thread Christian Weisgerber
(This is in a different part of the file from Theo's current efforts.) For large reads from /dev/random, use the arc4random_ctx_*() functions instead of hand-rolling the same code to set up a temporary ChaCha instance. ok? Index: rnd.c

  1   2   3   4   5   >