Re: [Diff] Implement multiple device cloning for hotplug

2021-05-11 Thread Theo de Raadt
Ashton Fagg wrote: > On May 11, 2021, at 22:53, Theo de Raadt wrote: > > This is because the design of hotplug is completely broken. > > Thank you, Theo, for the comprehensive reply. This was just the sort of > feedback I’d hoped to get. > > Ok so we have established this is a terrible idea b

Re: [Diff] Implement multiple device cloning for hotplug

2021-05-11 Thread Ashton Fagg
On May 11, 2021, at 22:53, Theo de Raadt wrote: > This is because the design of hotplug is completely broken. Thank you, Theo, for the comprehensive reply. This was just the sort of feedback I’d hoped to get. Ok so we have established this is a terrible idea because of the way hotplug works. :

Re: [Diff] Implement multiple device cloning for hotplug

2021-05-11 Thread Theo de Raadt
Ashton Fagg wrote: > The committed diff fixes my original problem. However, I've now > encountered another one. On one of my machines (far slower than the > first one), the devices themselves are much slower to attach - this > leads to the same race condition as before, as "iscsictl reload" is on

[Diff] Implement multiple device cloning for hotplug

2021-05-11 Thread Ashton Fagg
Attached is a diff that implements device cloning to allow the /dev/hotplug device to be cloned (to allow multiple concurrent readers). Rationale: Currently, iscsid/iscsictl cannot see when the connections it initiates results in a device (disk) being attached. Recently, Claudio Jeker committed a

Re: potentially uninitialized string printed by vmd

2021-05-11 Thread Mike Larkin
On Mon, Mar 15, 2021 at 09:29:29AM +, James Cook wrote: > > The array "base" which is passed to log_warnx might be uninitialized: > > virtio_get_base doesn't necessarily touch it if it returns -1. Maybe it > > would be better just omit base from the output, e.g. > > > > log_warnx("vm \"%s\"

Re: services(5): more cleanup

2021-05-11 Thread Kurt Mosiejczuk
On Wed, May 12, 2021 at 01:13:55AM +0200, Jeremie Courreges-Anglas wrote: > I'd like to drop SWAT, unofficial and dropped by the samba project > around the switch to samba4. > > - moved smtps/465 to the standards section (rfc8314) > The new service was named "submissions". I guess we should use

services(5): more cleanup

2021-05-11 Thread Jeremie Courreges-Anglas
On Wed, May 05 2021, Stuart Henderson wrote: > On 2021/05/04 12:07, Jan Klemkow wrote: >> Hi, >> >> Add missing ftps defaults ports to servies(5). >> >> OK? >> >> bye, >> Jan >> >> Index: services >> === >> RCS file: /cvs/src/etc/

Re: athn(4): fix corrupt input frames

2021-05-11 Thread Mikolaj Kucharski
On Tue, May 11, 2021 at 04:12:34PM +0200, Stefan Sperling wrote: > kettenis@ noticed that an athn(4) node cache can contain bogus clients > with MAC addreses that look like bit-flipped versions of MAC addresses > of legitimate clients. > > I think this is due to my recent fix to allow block ack re

Re: macppc bsd.mp pmap's hash lock

2021-05-11 Thread Dale Rahn
This structure really should be cache-line aligned, which should prevent it from spilling across a page boundary. The powerpc pmap was originally designed to have 8 'way' locks so that only a single way would get locked, thus (as long as one doesn't have way more than 8 cores) any core should be

athn(4): fix corrupt input frames

2021-05-11 Thread Stefan Sperling
kettenis@ noticed that an athn(4) node cache can contain bogus clients with MAC addreses that look like bit-flipped versions of MAC addresses of legitimate clients. I think this is due to my recent fix to allow block ack requests to pass through athn(4). The driver calls ieee80211_find_rxnode() o

Re: fix rpki-client on alpine using libressl

2021-05-11 Thread Theo Buehler
On Tue, May 11, 2021 at 01:01:13PM +0200, Claudio Jeker wrote: > So on Alpine Linux the libressl version is older then the fix to > ASN1_time_parse (rev 1.16 of lib/libcrypto/asn1/a_time_tm.c). > Because of this the expire times shown in the CSV and JSON output are all > over the place. > > Lets a

Re: rpki-client fix possible uninitalised variables

2021-05-11 Thread Theo Buehler
On Tue, May 11, 2021 at 09:51:22AM +0200, Claudio Jeker wrote: > Modern gcc warns about these variables being not initalized. > > main.c: In function 'main': > main.c:1064:11: warning: 'rrdppid' may be used uninitialized in this function > [-Wmaybe-uninitialized] >else if (pid == rrdppid) >

fix rpki-client on alpine using libressl

2021-05-11 Thread Claudio Jeker
So on Alpine Linux the libressl version is older then the fix to ASN1_time_parse (rev 1.16 of lib/libcrypto/asn1/a_time_tm.c). Because of this the expire times shown in the CSV and JSON output are all over the place. Lets add explicit memset before calling ASN1_time_parse() to make this work even

Re: bgpd fix for rde evaluate all

2021-05-11 Thread Claudio Jeker
On Tue, May 04, 2021 at 09:55:32AM +0200, Claudio Jeker wrote: > Noticed by the arouteserver author Pier Carlo Chiodi the new rde evaluate > all feature has a bug when a 2nd best route is withdrawn. In that case > that route got not withdrawn from the adj-rib-out. > > The problem is in up_generate

rpki-client fix possible uninitalised variables

2021-05-11 Thread Claudio Jeker
Modern gcc warns about these variables being not initalized. main.c: In function 'main': main.c:1064:11: warning: 'rrdppid' may be used uninitialized in this function [-Wmaybe-uninitialized] else if (pid == rrdppid) ^ rrdp_delta.c: In function 'start_publish_withdraw_elem': rrdp_de