Re: timekeep: fixing large skews on amd64 with RDTSCP

2020-08-22 Thread Scott Cheloha
On Tue, Jul 28, 2020 at 10:02:07AM +0300, Paul Irofti wrote: > > [...] > > Is the issue with LFENCE slowing down the network stack settled? That was > the argument against it last time. ... a month passes. Nobody says anything. This "it might slow down the network stack" thing keeps coming

Re: top: filter by routing table

2020-08-22 Thread Todd C . Miller
This looks good to me but I've refrained from commenting simply because I don't use rtables at all myself. Can we get some feedback from people who actually use rtables? - todd

Improve semantics and punctuation in ifconfig.8

2020-08-22 Thread Evan Silberman
Not to provoke a deep philosophical debate about the difference between Ql, Cm, and Sy, but surely Em isn't the best choice here. A couple other nits that bothered me in the same general region, I guess your taste might vary. Evan Silberman --- commit

Re: top: filter by routing table

2020-08-22 Thread Klemens Nanni
On Sun, Aug 09, 2020 at 09:02:14PM +0200, Klemens Nanni wrote: > Sometimes I want to see processes outside the default routing table with > `-T -0', sometimes those in in a specific one with `-T 3' (for testing). > > Since others have poked around with routing tables and/or domains as of > late,

Re: sppp: add size to free() calls

2020-08-22 Thread Vitaliy Makkoveev
Yeah, we override both of 'auth->name' and 'auth->secret’. Since there is the only difference against your previous diff and the only place where you touch them I have no objections. > On 22 Aug 2020, at 18:00, Klemens Nanni wrote: > > On Sat, Aug 22, 2020 at 02:32:17PM +0200, Klemens Nanni

Re: sppp: add size to free() calls

2020-08-22 Thread Klemens Nanni
On Sat, Aug 22, 2020 at 02:32:17PM +0200, Klemens Nanni wrote: > Another round, this time obvious sizes which are in immediate scope of > the free() call, e.g. right below the malloc() call. > > This leaves only a few selected free() calls with size zero in > if_spppsubr.c due to the fact that

Re: sppp: add size to free() calls

2020-08-22 Thread Vitaliy Makkoveev
ok mvs@ > On 22 Aug 2020, at 15:32, Klemens Nanni wrote: > > Another round, this time obvious sizes which are in immediate scope of > the free() call, e.g. right below the malloc() call. > > This leaves only a few selected free() calls with size zero in > if_spppsubr.c due to the fact that

ntpd: go into unsynced mode

2020-08-22 Thread Otto Moerbeek
Hi, At the moment ntpd never goes into unsynced mode if network connectivity is lost. The code to do that is only triggered when a pakcet is received, which does not happen. This diff fixes that by going into unsynced mode if no time data was processed for a while. An earlier version of this

Re: sdmmc(4): add UHS-I support

2020-08-22 Thread Marcus Glocker
On Sat, 22 Aug 2020 14:09:53 +0200 (CEST) Mark Kettenis wrote: > > Date: Mon, 17 Aug 2020 12:57:58 +0200 (CEST) > > From: Mark Kettenis > > > > > Date: Sun, 16 Aug 2020 19:32:03 +0200 (CEST) > > > From: Mark Kettenis > > > > > > The diff below adds support for higher speeds as supported by

sppp: add size to free() calls

2020-08-22 Thread Klemens Nanni
Another round, this time obvious sizes which are in immediate scope of the free() call, e.g. right below the malloc() call. This leaves only a few selected free() calls with size zero in if_spppsubr.c due to the fact that there is currently no variable to keep track of username and password

Re: sdmmc(4): add UHS-I support

2020-08-22 Thread Mark Kettenis
> Date: Mon, 17 Aug 2020 12:57:58 +0200 (CEST) > From: Mark Kettenis > > > Date: Sun, 16 Aug 2020 19:32:03 +0200 (CEST) > > From: Mark Kettenis > > > > The diff below adds support for higher speeds as supported by UHS-I SD > > cards to the generic sdmmc(4) layer. The diff in itself does not >

Re: snmpd(8) Remove struct listen_sock

2020-08-22 Thread Jan Klemkow
On Sun, Aug 09, 2020 at 04:10:13PM +0200, Martijn van Duren wrote: > I still want to move udp/tcp handling out of snmpe, so that there's > better layering, but my previous diff never got any response and might > do with some more polishing. > > For now, lets remove listen_sock from snmpd,