Re: timeout(9): add clock-based timeouts (attempt 2)

Scott Cheloha writes: > On Fri, Sep 04, 2020 at 05:55:40PM -0500, Scott Cheloha wrote: >> On Sat, Jul 25, 2020 at 08:46:08PM -0500, Scott Cheloha wrote: >> > Basically, ticks are a poor approximation for the system clock. We >> > should use the real thing where possible. >> > >> > [...] >> >

Re: clang warning in vmctl

On Wed, Sep 02, 2020 at 01:49:02PM -0600, Theo de Raadt wrote: > I had this diff in my tree for a while, but haven't gotten around > to passing it up. > > there are other warnings in the tree, found by newer clang, that > people should review. Some of them are just noise, in particular > relating

Re: httpd.conf.5 TLS defaults

On Fri, Sep 04, 2020 at 08:48:48PM -0700, na...@airpost.net wrote: > This is TLS v1.2 & 1.3 now. Delete it here, since the referenced man page is > updated. Thanks, I'm ok with this diff. I had the diff below in my tree for a long time (I think it was prompted by a question of tj). I did mention

httpd.conf.5 TLS defaults

This is TLS v1.2 & 1.3 now. Delete it here, since the referenced man page is updated. Index: httpd.conf.5 === RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v retrieving revision 1.112 diff -u -p -r1.112 httpd.conf.5 --- httpd.conf.5

Probably useless patch to initial GDT

I doubt this will ever matter, but I think this is correct. I hope this isn't an annoying patch. Just trying to get my feet wet in the kernel. It compiled and ran on my machine for what it's worth. Chris Waddey Index: gidt.S === RCS

Re: timeout(9): add clock-based timeouts (attempt 2)

On Fri, Sep 04, 2020 at 05:55:40PM -0500, Scott Cheloha wrote: > On Sat, Jul 25, 2020 at 08:46:08PM -0500, Scott Cheloha wrote: > > > > [...] > > > > I want to add clock-based timeouts to the kernel because tick-based > > timeouts suffer from a few problems: > > > > [...] > > > > Basically, tic

Re: Allow builds on arm64 without DDB

On Fri, Sep 04, 2020 at 08:55:30AM -0600, Theo de Raadt wrote: > Too much ifdef. Can you try a different approach -- leave the ipi code > intact, but wrap the call to db_enter() with #ifdef DDB? The ipi won't > be activated, so it should be fine for it to return 0. Thanks Theo. I just tried to t

Re: incorrect result from getppid for ptraced processes

On Fri, Sep 4, 2020 at 2:59 PM Mateusz Guzik wrote: > On 9/5/20, Philip Guenther wrote: > > On Fri, Sep 4, 2020 at 1:06 PM Mateusz Guzik wrote: > > > >> On 9/4/20, Vitaliy Makkoveev wrote: > >> > On Fri, Sep 04, 2020 at 05:24:42PM +0200, Mateusz Guzik wrote: > >> >> getppid blindly follows the

Re: incorrect result from getppid for ptraced processes

On 9/5/20, Philip Guenther wrote: > On Fri, Sep 4, 2020 at 1:06 PM Mateusz Guzik wrote: > >> On 9/4/20, Vitaliy Makkoveev wrote: >> > On Fri, Sep 04, 2020 at 05:24:42PM +0200, Mateusz Guzik wrote: >> >> getppid blindly follows the parent pointer and reads the pid. >> >> >> >> The problem is that

Re: incorrect result from getppid for ptraced processes

On Fri, Sep 4, 2020 at 1:06 PM Mateusz Guzik wrote: > On 9/4/20, Vitaliy Makkoveev wrote: > > On Fri, Sep 04, 2020 at 05:24:42PM +0200, Mateusz Guzik wrote: > >> getppid blindly follows the parent pointer and reads the pid. > >> > >> The problem is that ptrace reparents the traced process, so in

Re: timeout(9): add clock-based timeouts (attempt 2)

On Sat, Jul 25, 2020 at 08:46:08PM -0500, Scott Cheloha wrote: > > [...] > > I want to add clock-based timeouts to the kernel because tick-based > timeouts suffer from a few problems: > > [...] > > Basically, ticks are a poor approximation for the system clock. We > should use the real thing w

Re: incorrect result from getppid for ptraced processes

On 9/4/20, Vitaliy Makkoveev wrote: > On Fri, Sep 04, 2020 at 05:24:42PM +0200, Mateusz Guzik wrote: >> getppid blindly follows the parent pointer and reads the pid. >> >> The problem is that ptrace reparents the traced process, so in >> particular if you gdb -p $something, the target proc will st

dmesg submitting tool

A problem I see: It's often hard to submit a dmesg. These days, sending e-mail from an arbitrary machine is "difficult", as it usually requires use of an e-mail relay. Gathering and sending a dmesg via many common e-mail clients often ends up mangling the dmesg in various ways. Goals for a solu

Re: incorrect result from getppid for ptraced processes

On Fri, Sep 04, 2020 at 05:24:42PM +0200, Mateusz Guzik wrote: > getppid blindly follows the parent pointer and reads the pid. > > The problem is that ptrace reparents the traced process, so in > particular if you gdb -p $something, the target proc will start seeing > gdb instead of its actual par

Re: [PATCH] Add IOMMU support for Intel VT-d and AMD-Vi

> Date: Fri, 4 Sep 2020 00:50:44 -0500 > From: Jordan Hargrave A few hints below... > > > + > > > +/* Page Table Entry per domain */ > > > +static struct ivhd_dte hwdte[65536] __aligned(PAGE_SIZE); > > > + > > > +/* Alias mapping */ > > > +#define SID_INVALID 0x8000L > > > +static uint32_t s

incorrect result from getppid for ptraced processes

getppid blindly follows the parent pointer and reads the pid. The problem is that ptrace reparents the traced process, so in particular if you gdb -p $something, the target proc will start seeing gdb instead of its actual parent. There is a lot to say about the entire reparenting business or stor

Re: Allow builds on arm64 without DDB

Too much ifdef. Can you try a different approach -- leave the ipi code intact, but wrap the call to db_enter() with #ifdef DDB? The ipi won't be activated, so it should be fine for it to return 0. Matt Baulch wrote: > Currently, it's not possible to build on arm64 without the in-kernel debugge

Allow builds on arm64 without DDB

Currently, it's not possible to build on arm64 without the in-kernel debugger. This patch fixes the two offending files: Index: agintc.c === RCS file: /cvs/src/sys/arch/arm64/dev/agintc.c,v retrieving revision 1.26 diff -u -p -u -p -r