Re: httpd.conf.5 TLS defaults

2020-09-04 Thread Theo Buehler
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

2020-09-04 Thread navan
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 ---

Probably useless patch to initial GDT

2020-09-04 Thread Chris Waddey
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 ===

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

2020-09-04 Thread Scott Cheloha
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,

Re: Allow builds on arm64 without DDB

2020-09-04 Thread Matt Baulch
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

Re: incorrect result from getppid for ptraced processes

2020-09-04 Thread Philip Guenther
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

Re: incorrect result from getppid for ptraced processes

2020-09-04 Thread Mateusz Guzik
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

Re: incorrect result from getppid for ptraced processes

2020-09-04 Thread Philip Guenther
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

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

2020-09-04 Thread Scott Cheloha
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

Re: incorrect result from getppid for ptraced processes

2020-09-04 Thread Mateusz Guzik
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

dmesg submitting tool

2020-09-04 Thread Nick Holland
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

Re: incorrect result from getppid for ptraced processes

2020-09-04 Thread Vitaliy Makkoveev
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

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

2020-09-04 Thread Mark Kettenis
> 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

incorrect result from getppid for ptraced processes

2020-09-04 Thread Mateusz Guzik
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

Re: Allow builds on arm64 without DDB

2020-09-04 Thread Theo de Raadt
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

Allow builds on arm64 without DDB

2020-09-04 Thread Matt Baulch
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