Re: switch(4): fix netlock assertion within ifpromisc()
On 19.2.2021. 21:50, Vitaliy Makkoveev wrote: > As it was reported [1] switch(4) triggers NET_ASSERT_LOCKED() while > we perform ifconfig(8) destroy. ifpromisc() requires netlock to be held. > This is true while switch_port_detach() and underlay ifpromisc() called > through switch_ioctl(). But while we destroy switch(4) interface we call > ifpromisc() without netlock. We can't add netlock just around > ifpromisc() because switch_port_detach() which calls it called by > switch_ioctl() with netlock held and by switch_clone_destroy() without > netlock held. So the solution is to add netlock to destroy path. Diff > below adds it around the whole foreach loop where we call > switch_port_detach(). > > 1. https://marc.info/?l=openbsd-bugs=161338077403538=2 i'm confirming that there are no more logs .. tnx ..
Re: ping graphical display
Canvassing opinions on having . and ! this way around. I'm using . for response, ! for no response, which makes more sense to me but it's been pointed out that it's the opposite of what cisco does so it might confuse some people.
switch(4): fix netlock assertion within ifpromisc()
As it was reported [1] switch(4) triggers NET_ASSERT_LOCKED() while
we perform ifconfig(8) destroy. ifpromisc() requires netlock to be held.
This is true while switch_port_detach() and underlay ifpromisc() called
through switch_ioctl(). But while we destroy switch(4) interface we call
ifpromisc() without netlock. We can't add netlock just around
ifpromisc() because switch_port_detach() which calls it called by
switch_ioctl() with netlock held and by switch_clone_destroy() without
netlock held. So the solution is to add netlock to destroy path. Diff
below adds it around the whole foreach loop where we call
switch_port_detach().
1. https://marc.info/?l=openbsd-bugs=161338077403538=2
Index: sys/net/if_switch.c
===
RCS file: /cvs/src/sys/net/if_switch.c,v
retrieving revision 1.40
diff -u -p -r1.40 if_switch.c
--- sys/net/if_switch.c 19 Jan 2021 19:39:14 - 1.40
+++ sys/net/if_switch.c 19 Feb 2021 20:24:37 -
@@ -196,6 +196,7 @@ switch_clone_destroy(struct ifnet *ifp)
struct switch_port *swpo, *tp;
struct ifnet*ifs;
+ NET_LOCK();
TAILQ_FOREACH_SAFE(swpo, >sc_swpo_list, swpo_list_next, tp) {
if ((ifs = if_get(swpo->swpo_ifindex)) != NULL) {
switch_port_detach(ifs);
@@ -204,6 +205,7 @@ switch_clone_destroy(struct ifnet *ifp)
log(LOG_ERR, "failed to cleanup on ifindex(%d)\n",
swpo->swpo_ifindex);
}
+ NET_UNLOCK();
LIST_REMOVE(sc, sc_switch_next);
bstp_destroy(sc->sc_stp);
swofp_destroy(sc);
Re: if calloc() needs nmemb and size, why doesn't freezero()?
I used the verbiage: “malloc(3)” as a general all-encompassing manpage which includes malloc(), calloc(), freezero(), etc. Sorry for the confusion. > In malloc(3): >> > “If you use smaller integer types than size_t for ‘nmemb’ and ‘size’, >> then >> > multiplication in freezero() may need to be cast to size_t to avoid >> integer >> > overflow: >> > freezero(ptr, (size_t)nmemb * (size_t)size);” >> > Or maybe even: freezero(ptr, (size_t)nmemb * size); >> >> This is bad advice. The product of two size_t values can exceed >> SIZE_MAX, at which point you would get integer overflow. This is >> why the malloc(3) man page warns against it. Note that on 64-bit >> platforms like amd64, size_t is already 64-bit so casting to unsigned >> long long or uint64_t is not effective. >> >> On OpenBSD, calloc(3) and reallocarray(3) check for integer overflow >> for you, which is why they are preferred over malloc(nmemb * size). >> You can examing the code yourself: >> http://cvsweb.openbsd.org/src/lib/libc/stdlib/reallocarray.c?rev=1.3 >> >> - todd >> > -- > -Luke > -- -Luke
Re: doas needs doas.conf
Jan Stary wrote: > Say explicitly that doas needs doas.conf to exist, > and point to the example one. > > Jan > > > Index: doas.1 > === > RCS file: /cvs/src/usr.bin/doas/doas.1,v > retrieving revision 1.25 > diff -u -p -r1.25 doas.1 > --- doas.116 Jan 2021 09:18:41 - 1.25 > +++ doas.119 Feb 2021 19:20:58 - > @@ -43,6 +43,15 @@ is specified. > The user will be required to authenticate by entering their password, > unless configured otherwise. > .Pp > +.Nm > +will not execute the > +.Ar command > +if the file > +.Pa /etc/doas.conf > +does not exist. I disagree. It is immediately obvious that doas requires explicit configuration. In use, this is quickly discovered by trying to use doas: % doas sadf doas: doas is not enabled, /etc/doas.conf: No such file or directory I think you took some time trying to figure out where to add the sentence. Early on it does not work. But later on, I think it doesn't work either. Some text which might work would be The doas utility executes the given command as another user, based upon explicit configuration. or The doas utility executes the given command as another user, based upon explicit configuration in /etc/doas.conf. > +An example is provided in > +.Pa /etc/examples/ . > +.Pp ... > +.Sh FILES > +.Bl -tag -compact > +.It Pa /etc/doas.conf > +.It Pa /etc/examples/doas.conf > .El This is already documented in doas.conf(5) FILES /etc/doas.conf doas(1) configuration file. /etc/examples/doas.conf Example configuration file. That is how we do it in other subsystems, for example bgpd(8) mentions FILES /etc/bgpd.conf default bgpd configuration file /var/run/bgpd.sock default bgpd control socket SEE ALSO bgpd.conf(5), bgpctl(8), bgplg(8), bgplgsh(8) and then bgpd.conf(5) points at the example FILES /etc/bgpd.conf bgpd(8) configuration file. /etc/examples/bgpd.conf Example configuration file. We have intentionally documented the examples at the end of the documentation chain. Noone should be looking at or using an example configuration, until they have completed reading the configuration docs. The use of examples without comprehension is very dangerous, and nearly stopped us from including examples at all...
doas needs doas.conf
Say explicitly that doas needs doas.conf to exist, and point to the example one. Jan Index: doas.1 === RCS file: /cvs/src/usr.bin/doas/doas.1,v retrieving revision 1.25 diff -u -p -r1.25 doas.1 --- doas.1 16 Jan 2021 09:18:41 - 1.25 +++ doas.1 19 Feb 2021 19:20:58 - @@ -43,6 +43,15 @@ is specified. The user will be required to authenticate by entering their password, unless configured otherwise. .Pp +.Nm +will not execute the +.Ar command +if the file +.Pa /etc/doas.conf +does not exist. +An example is provided in +.Pa /etc/examples/ . +.Pp By default, a new environment is created. The variables .Ev HOME , @@ -110,6 +119,11 @@ or Execute the command as .Ar user . The default is root. +.El +.Sh FILES +.Bl -tag -compact +.It Pa /etc/doas.conf +.It Pa /etc/examples/doas.conf .El .Sh EXIT STATUS .Ex -std doas
Re: if calloc() needs nmemb and size, why doesn't freezero()?
I agree it can overflow. But if you use the same variables with the same values plugged into ptr = calloc(nmemb, size); as you use in freezero(ptr, (size_t)nmemb * size); If it can overflow, it will have done it already in calloc(). On Fri, Feb 19, 2021 at 12:23 PM Todd C. Miller wrote: > On Fri, 19 Feb 2021 10:38:13 -0600, Luke Small wrote: > > > In malloc(3): > > “If you use smaller integer types than size_t for ‘nmemb’ and ‘size’, > then > > multiplication in freezero() may need to be cast to size_t to avoid > integer > > overflow: > > freezero(ptr, (size_t)nmemb * (size_t)size);” > > Or maybe even: freezero(ptr, (size_t)nmemb * size); > > This is bad advice. The product of two size_t values can exceed > SIZE_MAX, at which point you would get integer overflow. This is > why the malloc(3) man page warns against it. Note that on 64-bit > platforms like amd64, size_t is already 64-bit so casting to unsigned > long long or uint64_t is not effective. > > On OpenBSD, calloc(3) and reallocarray(3) check for integer overflow > for you, which is why they are preferred over malloc(nmemb * size). > You can examing the code yourself: > http://cvsweb.openbsd.org/src/lib/libc/stdlib/reallocarray.c?rev=1.3 > > - todd > -- -Luke
Re: if calloc() needs nmemb and size, why doesn't freezero()?
On Fri, 19 Feb 2021 10:38:13 -0600, Luke Small wrote: > In malloc(3): > “If you use smaller integer types than size_t for ‘nmemb’ and ‘size’, then > multiplication in freezero() may need to be cast to size_t to avoid integer > overflow: > freezero(ptr, (size_t)nmemb * (size_t)size);” > Or maybe even: freezero(ptr, (size_t)nmemb * size); This is bad advice. The product of two size_t values can exceed SIZE_MAX, at which point you would get integer overflow. This is why the malloc(3) man page warns against it. Note that on 64-bit platforms like amd64, size_t is already 64-bit so casting to unsigned long long or uint64_t is not effective. On OpenBSD, calloc(3) and reallocarray(3) check for integer overflow for you, which is why they are preferred over malloc(nmemb * size). You can examing the code yourself: http://cvsweb.openbsd.org/src/lib/libc/stdlib/reallocarray.c?rev=1.3 - todd
Teach rpki-client some https
Some TAL files now include an https URI where the TA can be fetched from.
With this diff rpki-client will download the TA from https unless that
fails and then fall back to rsync.
This is not yet perfect but the diff is already large enough (adding a
full event based https client based on ftp codebase). For RRDP more a lot
more is required and I probably will refactor the main.c code then.
At the moment this adds a local mkostempat() function to implement
mkostemp() but with openat() instead of open(). I hope in the future libc
will provide something.
Thanks in advance for all the feedback
--
:wq Claudio
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/rpki-client/Makefile,v
retrieving revision 1.18
diff -u -p -r1.18 Makefile
--- Makefile4 Feb 2021 08:10:24 - 1.18
+++ Makefile19 Feb 2021 14:21:08 -
@@ -1,13 +1,14 @@
# $OpenBSD: Makefile,v 1.18 2021/02/04 08:10:24 claudio Exp $
PROG= rpki-client
-SRCS= as.c cert.c cms.c crl.c gbr.c io.c ip.c log.c main.c mft.c mkdir.c \
- output.c output-bgpd.c output-bird.c output-csv.c output-json.c \
- parser.c roa.c rsync.c tal.c validate.c x509.c
+SRCS= as.c cert.c cms.c crl.c gbr.c http.c io.c ip.c log.c main.c mft.c \
+ mkdir.c mkostempat.c output.c output-bgpd.c output-bird.c \
+ output-csv.c output-json.c parser.c roa.c rsync.c tal.c validate.c \
+ x509.c
MAN= rpki-client.8
-LDADD+= -lcrypto -lutil
-DPADD+= ${LIBCRYPTO} ${LIBUTIL}
+LDADD+= -ltls -lssl -lcrypto -lutil
+DPADD+= ${LIBTLS} ${LIBSSL} ${LIBCRYPTO} ${LIBUTIL}
CFLAGS+= -Wall -I${.CURDIR}
CFLAGS+= -Wstrict-prototypes -Wmissing-prototypes
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.46
diff -u -p -r1.46 extern.h
--- extern.h19 Feb 2021 08:14:49 - 1.46
+++ extern.h19 Feb 2021 14:20:27 -
@@ -399,6 +399,10 @@ voidproc_parser(int) __attribute__((n
char *rsync_base_uri(const char *);
voidproc_rsync(char *, char *, int) __attribute__((noreturn));
+/* Http-specific. */
+
+voidproc_http(char *, int);
+
/* Logging (though really used for OpenSSL errors). */
voidcryptowarnx(const char *, ...)
@@ -417,6 +421,7 @@ void io_str_buffer(struct ibuf *, cons
voidio_simple_read(int, void *, size_t);
voidio_buf_read_alloc(int, void **, size_t *);
voidio_str_read(int, char **);
+int io_recvfd(int, void *, size_t);
/* X509 helpers. */
@@ -449,7 +454,8 @@ int output_json(FILE *, struct vrp_tre
void logx(const char *fmt, ...)
__attribute__((format(printf, 1, 2)));
-intmkpath(int, const char *);
+intmkpathat(int, const char *);
+intmkostempat(int, char *, int);
#defineRPKI_PATH_OUT_DIR "/var/db/rpki-client"
#defineRPKI_PATH_BASE_DIR "/var/cache/rpki-client"
Index: http.c
===
RCS file: http.c
diff -N http.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ http.c 19 Feb 2021 17:32:26 -
@@ -0,0 +1,1223 @@
+/*
+ * Copyright (c) 2020 Nils Fisher
+ * Copyright (c) 2020 Claudio Jeker
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+/* $OpenBSD: fetch.c,v 1.197 2020/07/04 11:23:35 kn Exp $ */
+/* $NetBSD: fetch.c,v 1.14 1997/08/18 10:20:20 lukem Exp $ */
+
+/*-
+ * Copyright (c) 1997 The NetBSD Foundation, Inc.
+ * All rights reserved.
+ *
+ * This code is derived from software contributed to The NetBSD Foundation
+ * by Jason Thorpe and Luke Mewburn.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ *
Re: if calloc() needs nmemb and size, why doesn't freezero()?
>
> > In the manpage you could succinctly state:
> >
> > In malloc(3):
> > “If you use smaller integer types than size_t for ‘nmemb’ and ‘size’,
> then
> multiplication in freezero() may need to be cast to size_t to avoid
> integer overflow:
> > freezero(ptr, (size_t)nmemb * (size_t)size);”
> > Or maybe even: freezero(ptr, (size_t)nmemb * size);
>
> That is incorrect.
If it’s functionally incorrect, then tell me how the following cast acts
equivalently to intermediate storage or at least calls operations which act
upon uint64_t and makes the function return what is obviously intended on
your OpenBSD:
uint64_t bufferToTime(const u_char buf[])
{
return (( (( (( (( (( (( ((
(uint64_t) buf[7]) << 8)
| buf[6]) << 8)
| buf[5]) << 8)
| buf[4]) << 8)
| buf[3]) << 8)
| buf[2]) << 8)
| buf[1]) << 8)
| buf[0];
}
Because it works.
--
-Luke
Re: ping graphical display
Hey,
i really like this representation of the results. Very usefull to keep
an eye on a lot of hosts during network related debugging.
Works fine for me. This just as feedback for you.
Greetings
Leo
Am 19.02.2021 um 16:19 schrieb Stuart Henderson:
This diff adds something similar to cisco's ping display, giving a
visual display of good/dropped pings. Any interest in it? Example
output (with a couple of ^T during the run):
$ ping -g 192.168.41.21
PING 192.168.41.21 (192.168.41.21): 56 data bytes
load:
0.04 cmd: ping 8312 [running] 0.00u 0.00s 0% 117k
--- 192.168.41.21 ping statistics ---
212 packets transmitted, 212 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.342/0.636/28.579/1.940 ms
.!!...!!!...!.!!!...!!!...!.!!!.....!.!!!.....!.!!!.....!!....!!....!!..!..load:
0.00 cmd: ping 8312 [running] 0.00u 0.00s 0% 118k
--- 192.168.41.21 ping statistics ---
924 packets transmitted, 800 packets received, 13.4% packet loss
round-trip min/avg/max/std-dev = 0.304/0.618/41.986/1.933 ms
(and while I'm there, if anyone has an idea why this one machine being
pinged, which is a 6.8 box with em(4), might periodically stop receiving
packets from a couple of hosts in the subnet while things are working
ok for others, I'm all ears ;) no interface errors, netlivelocks, etc.)
Index: ping.8
===
RCS file: /cvs/src/sbin/ping/ping.8,v
retrieving revision 1.63
diff -u -p -r1.63 ping.8
--- ping.8 11 Feb 2020 18:41:39 - 1.63
+++ ping.8 19 Feb 2021 15:11:19 -
@@ -66,7 +66,7 @@
.Nd send ICMP ECHO_REQUEST packets to network hosts
.Sh SYNOPSIS
.Nm ping
-.Op Fl DdEefHLnqRv
+.Op Fl DdEefgHLnqRv
.Op Fl c Ar count
.Op Fl I Ar sourceaddr
.Op Fl i Ar interval
@@ -79,7 +79,7 @@
.Op Fl w Ar maxwait
.Ar host
.Nm ping6
-.Op Fl DdEefHLmnqv
+.Op Fl DdEefgHLmnqv
.Op Fl c Ar count
.Op Fl h Ar hoplimit
.Op Fl I Ar sourceaddr
@@ -151,6 +151,21 @@ Only the superuser may use this option.
.Bf -emphasis
This can be very hard on a network and should be used with caution.
.Ef
+.It Fl g
+Graphic display.
+This provides a quick visual display of packets received and lost.
+For every
+.Dv ECHO_REPLY
+received, a period
+.Sq \&.
+is printed, while for every missed packet an exclamation mark
+.Sq !
+is printed.
+Duplicate and truncated replies are indicated with
+.Sq D
+and
+.Sq T
+respectively.
.It Fl H
Try reverse lookups for addresses.
.It Fl h Ar hoplimit
Index: ping.c
===
RCS file: /cvs/src/sbin/ping/ping.c,v
retrieving revision 1.243
diff -u -p -r1.243 ping.c
--- ping.c 29 Dec 2020 16:40:47 - 1.243
+++ ping.c 19 Feb 2021 15:11:19 -
@@ -145,7 +145,7 @@ int options;
#define F_QUIET 0x0010
#define F_RROUTE0x0020
#define F_SO_DEBUG 0x0040
-/* 0x0080 */
+#defineF_GRAPHIC 0x0080
#define F_VERBOSE 0x0100
/*0x0200 */
#define F_HDRINCL 0x0400
@@ -297,8 +297,8 @@ main(int argc, char *argv[])
preload = 0;
datap = [ECHOLEN + ECHOTMLEN];
while ((ch = getopt(argc, argv, v6flag ?
- "c:DdEefHh:I:i:Ll:mNnp:qS:s:T:V:vw:" :
- "DEI:LRS:c:defHi:l:np:qs:T:t:V:vw:")) != -1) {
+ "c:DdEefgHh:I:i:Ll:mNnp:qS:s:T:V:vw:" :
+ "DEI:LRS:c:defgHi:l:np:qs:T:t:V:vw:")) != -1) {
switch(ch) {
case 'c':
npackets = strtonum(optarg, 0, INT64_MAX, );
@@ -326,6 +326,9 @@ main(int argc, char *argv[])
options |= F_FLOOD;
setvbuf(stdout, NULL, _IONBF, 0);
break;
+ case 'g':
+ options |= F_GRAPHIC;
+ break;
case 'H':
options |= F_HOSTNAME;
break;
@@ -879,6 +882,11 @@ main(int argc, char *argv[])
if (!(options & F_FLOOD) &&
Re: if calloc() needs nmemb and size, why doesn't freezero()?
Luke Small wrote:
> malloc(3) already speaks to programmers who might use int multiplication and
> telling
> them to test for int multiplication overflow in malloc(), so you presume that
> they are
> already prepared to use something smaller than size_t, when you could have
> just said:
> “only use size_t variables for integer types.” and cut out the int
> multiplication
> overflow test example.
It seems you don't understand C, and don't want to be taught.
> In the manpage you could succinctly state:
>
> In malloc(3):
> “If you use smaller integer types than size_t for ‘nmemb’ and ‘size’, then
> multiplication in freezero() may need to be cast to size_t to avoid integer
> overflow:
> freezero(ptr, (size_t)nmemb * (size_t)size);”
> Or maybe even: freezero(ptr, (size_t)nmemb * size);
That is incorrect.
> Or:
>
> void freeczero( size_t nmemb, size_t size)
> {
> freezero(nmemb * size);
> }
Not going to happen.
> I suspect that freezero() is already little more than:
>
> void freezero(void *ptr, size_t size)
> {
> explicit_bzero(ptr, size);
> free(ptr);
> }
Wrong.
Re: if calloc() needs nmemb and size, why doesn't freezero()?
malloc(3) already speaks to programmers who might use int multiplication
and telling them to test for int multiplication overflow in malloc(), so
you presume that they are already prepared to use something smaller than
size_t, when you could have just said:
“only use size_t variables for integer types.” and cut out the int
multiplication overflow test example.
In the manpage you could succinctly state:
In malloc(3):
“If you use smaller integer types than size_t for ‘nmemb’ and ‘size’, then
multiplication in freezero() may need to be cast to size_t to avoid integer
overflow:
freezero(ptr, (size_t)nmemb * (size_t)size);”
Or maybe even: freezero(ptr, (size_t)nmemb * size);
Or:
void freeczero( size_t nmemb, size_t size)
{
freezero(nmemb * size);
}
I suspect that freezero() is already little more than:
void freezero(void *ptr, size_t size)
{
explicit_bzero(ptr, size);
free(ptr);
}
On Fri, Feb 19, 2021 at 12:51 AM Otto Moerbeek wrote:
> On Thu, Feb 18, 2021 at 03:24:36PM -0600, Luke Small wrote:
>
> > However, calloc(ptr, nmemb, size) may have been called using smaller int
> > variable types which would overflow when multiplied. Where if the
> variables
> > storing the values passed to nmemb and size are less than or especially
> > equal to their original values, I think it’d be good to state that:
> >
> > freezero(ptr, (size_t)nmemb * (size_t)size);
> > is guaranteed to work, but
> > freezero(ptr, nmemb * size);
> > does not have that guarantee.
>
> Lets try to make things explicit.
>
> The function c() does the overflowe check like calloc does.
> The function f() takes a size_t.
>
> #include
> #include
>
> #define MUL_NO_OVERFLOW (1UL << (sizeof(size_t) * 4))
>
> void c(size_t nmemb, size_t size)
> {
> if ((nmemb >= MUL_NO_OVERFLOW || size >= MUL_NO_OVERFLOW) &&
> nmemb > 0 && SIZE_T_MAX / nmemb < size)
> printf("Overflow\n");
> else
> printf("%zu\n", nmemb * size);
> }
>
> void f(size_t m)
> {
> printf("%zu\n", m);
> }
>
> int
> main()
> {
> int a = INT_MAX;
> int b = INT_MAX;
> c(a, b);
> f(a * b);
> }
>
> Now the issues is that the multiplication in the last line of main()
> overflows:
>
> $ ./a.out
> 4611686014132420609
> 1
>
> because this is an int multiplication only after that the promotion to
> size_t is done.
>
> So you are right that this can happen, *if you are using the wrong
> types*. But I would argue that feeding anything other than either
> size_t or constants to calloc() is already wrong. You *have* to
> consider the argument conversion rules when feeding values to calloc()
> (or any function). To avoid having to think about those, start with
> size_t already for everything that is a size or count of a memory
> object.
>
> -Otto
>
--
-Luke
Re: occasional SSIGSEGV on C++ exception handling
> Date: Fri, 19 Feb 2021 16:43:10 +0100
> From: Otto Moerbeek
>
> On Fri, Feb 19, 2021 at 01:06:43PM +0100, Otto Moerbeek wrote:
>
> > On Fri, Feb 19, 2021 at 12:45:58PM +0100, Mark Kettenis wrote:
> >
> > > > Date: Fri, 19 Feb 2021 10:57:30 +0100
> > > > From: Otto Moerbeek
> > > >
> > > > Hi,
> > > >
> > > > working on PowerDNS Recursor, once in a while I'm seeing:
> > > >
> > > > #0 0x09fd67ef09dc in
> > > > libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR
> > > > (this=,
> > > > head=0x9fd67efc8e8 , elm=0x9fca04be900)
> > > > at
> > > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
> > > > 243 RB_GENERATE(CacheTree, CacheItem, entry, CacheCmp);
> > > > [Current thread is 1 (process 349420)]
> > > > (gdb) bt
> > > > #0 0x09fd67ef09dc in
> > > > libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR
> > > > (this=,
> > > > head=0x9fd67efc8e8 , elm=0x9fca04be900)
> > > > at
> > > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
> > > > #1 0x09fd67eeddef in
> > > > libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT
> > > > (this=,
> > > > head=, elm=)
> > > > at
> > > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
> > > > #2 libunwind::UnwindInfoSectionsCache::setUnwindInfoSectionsForPC
> > > > (this=, key=10983975073074,
> > > > uis=...) at
> > > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:237
> > > > #3 libunwind::UnwindCursor > > > libunwind::Registers_x86_64>::setInfoBasedOnIPRegister (
> > > > this=0x9fd2ca0aa68, isReturnAddress=)
> > > > at
> > > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindCursor.hpp:1891
> > > > #4 0x09fd67eedaa4 in
> > > > libunwind::UnwindCursor > > > libunwind::Registers_x86_64>::step (
> > > > this=0x9fd2ca0aa68) at
> > > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindCursor.hpp:2031
> > > > #5 0x09fd67ef15a4 in unwind_phase1 (uc=,
> > > > cursor=, exception_object=0x9fd37b24560)
> > > > at
> > > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindLevel1.c:46
> > > > #6 _Unwind_RaiseException (exception_object=0x9fd37b24560)
> > > > at
> > > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindLevel1.c:363
> > > > #7 0x09fd67eeb533 in __cxa_throw (thrown_object=0x9fd37b24580,
> > > > tinfo=0x9fa6c615a00 , dest= > > > out>)
> > > > at
> > > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libcxxabi/src/cxa_exception.cpp:279
> > > > #8 0x09fa6c295955 in ComboAddress::ComboAddress (this= > > > out>, str=..., port=)
> > > > at ./iputils.hh:219
> > > > #9 0x09fa6c489970 in startFrameStreamServers (config=...) at
> > > > pdns_recursor.cc:1248
> > > > #10 checkFrameStreamExport (luaconfsLocal=...) at pdns_recursor.cc:1290
> > > > #11 0x09fa6c48158f in recursorThread (n=,
> > > > ...
> > > >
> > > > This does not happen always, most of the time this exception is
> > > > handled correctly, afaik.
> > > >
> > > > The code that twrows an exception is:
> > > > try {
> > > > ComboAddress address(server);
> > > > ...
> > > > }
> > > > catch ...
> > > >
> > > > The ComboAddress constructor throws the exception (and is supposed to
> > > > do that). It looks like libunwind gets confused somehow.
> > > >
> > > > Any clue?
> > >
> > > The cache that pirofti@ added a while ago isn't thread-safe. Or maybe
> > > this is a use-after free caused by dlcose(4). We should probably
> > > disable/remove it while he is working on a better solution.
> > > Unfortunately I don't think adding locking here is a good idea so this
> > > may need a more fundamental rethink.
> > >
> > > Upstream did add an optimization in this area a few months ago:
> > >
> > >
> > > https://github.com/llvm/llvm-project/commit/881aba7071c6e4cc2417e875ca5027ec7c0a92a3
> > >
> > > The version of libunwind we're using is older than that, so it may be
> > > worth picking that up and see if that improves the original problem.
> >
> > First I'm going to try to fix it my making the cache thread_local.
> >
> > I'm probably going to regret looking at this code,
> >
> > -Otto
>
> The diff below works for my test case on amd64.
>
> It also feels right from a theoretical point of view. As for practical
> matters, if thread local storage isn't working properly, a lot more
> things would break. So I am a bit more optimisic about the diff now
> than this morning.
>
> So we have three options, I think:
>
> - back the caching out,
> - investigate the commit you mention above. Sadly I cannot
> remember the original case that prompted for the caching code to be
> added.
> - continue on the thread_local path
>
> We *have* to pick a solution. Having broken exception handling for
>
Re: ping graphical display
On 2021/02/19 15:19, Stuart Henderson wrote:
> This diff adds something similar to cisco's ping display, giving a
> visual display of good/dropped pings. Any interest in it? Example
> output (with a couple of ^T during the run):
>
> $ ping -g 192.168.41.21
> PING 192.168.41.21 (192.168.41.21): 56 data bytes
> load:
> 0.04 cmd: ping 8312 [running] 0.00u 0.00s 0% 117k
>
> --- 192.168.41.21 ping statistics ---
> 212 packets transmitted, 212 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 0.342/0.636/28.579/1.940 ms
> .!!...!!!...!.!!!...!!!...!.!!!.....!.!!!.....!.!!!.....!!....!!....!!..!..load:
> 0.00 cmd: ping 8312 [running] 0.00u 0.00s 0% 118k
>
> --- 192.168.41.21 ping statistics ---
> 924 packets transmitted, 800 packets received, 13.4% packet loss
> round-trip min/avg/max/std-dev = 0.304/0.618/41.986/1.933 ms
>
> (and while I'm there, if anyone has an idea why this one machine being
> pinged, which is a 6.8 box with em(4), might periodically stop receiving
> packets from a couple of hosts in the subnet while things are working
> ok for others, I'm all ears ;) no interface errors, netlivelocks, etc.)
I've tweaked the manpage change a bit.
It doesn't really make sense to combine with -F, should it just
err out like it does with -f and -i?
Index: ping.8
===
RCS file: /cvs/src/sbin/ping/ping.8,v
retrieving revision 1.63
diff -u -p -r1.63 ping.8
--- ping.8 11 Feb 2020 18:41:39 - 1.63
+++ ping.8 19 Feb 2021 16:10:53 -
@@ -66,7 +66,7 @@
.Nd send ICMP ECHO_REQUEST packets to network hosts
.Sh SYNOPSIS
.Nm ping
-.Op Fl DdEefHLnqRv
+.Op Fl DdEefgHLnqRv
.Op Fl c Ar count
.Op Fl I Ar sourceaddr
.Op Fl i Ar interval
@@ -79,7 +79,7 @@
.Op Fl w Ar maxwait
.Ar host
.Nm ping6
-.Op Fl DdEefHLmnqv
+.Op Fl DdEefgHLmnqv
.Op Fl c Ar count
.Op Fl h Ar hoplimit
.Op Fl I Ar sourceaddr
@@ -151,6 +151,20 @@ Only the superuser may use this option.
.Bf -emphasis
This can be very hard on a network and should be used with caution.
.Ef
+.It Fl g
+Provides a visual display of packets received and lost.
+For every
+.Dv ECHO_REPLY
+received, a period
+.Sq \&.
+is printed, while for every missed packet an exclamation mark
+.Sq !
+is printed.
+Duplicate and truncated replies are indicated with
+.Sq D
+and
+.Sq T
+respectively.
.It Fl H
Try reverse lookups for addresses.
.It Fl h Ar hoplimit
Index: ping.c
===
RCS file: /cvs/src/sbin/ping/ping.c,v
retrieving revision 1.243
diff -u -p -r1.243 ping.c
--- ping.c 29 Dec 2020 16:40:47 - 1.243
+++ ping.c 19 Feb 2021 16:10:53 -
@@ -145,7 +145,7 @@ int options;
#defineF_QUIET 0x0010
#defineF_RROUTE0x0020
#defineF_SO_DEBUG 0x0040
-/* 0x0080 */
+#defineF_GRAPHIC 0x0080
#defineF_VERBOSE 0x0100
/* 0x0200 */
#defineF_HDRINCL 0x0400
@@ -297,8 +297,8 @@ main(int argc, char *argv[])
preload = 0;
datap = [ECHOLEN + ECHOTMLEN];
while ((ch = getopt(argc, argv, v6flag ?
- "c:DdEefHh:I:i:Ll:mNnp:qS:s:T:V:vw:" :
- "DEI:LRS:c:defHi:l:np:qs:T:t:V:vw:")) != -1) {
+ "c:DdEefgHh:I:i:Ll:mNnp:qS:s:T:V:vw:" :
+ "DEI:LRS:c:defgHi:l:np:qs:T:t:V:vw:")) != -1) {
switch(ch) {
case 'c':
npackets = strtonum(optarg, 0, INT64_MAX, );
@@ -326,6 +326,9 @@ main(int argc, char *argv[])
options |= F_FLOOD;
setvbuf(stdout, NULL, _IONBF, 0);
break;
+ case 'g':
+ options |= F_GRAPHIC;
+ break;
case 'H':
options |= F_HOSTNAME;
break;
@@ -879,6 +882,11 @@ main(int argc, char *argv[])
if (!(options & F_FLOOD) &&
(options & F_AUD_MISS))
Re: ping graphical display
As a WISP manager always experiencing spaced-but-repeated packet-loss
mayhem, I'm loving it.
El vie, 19 feb 2021 a las 16:22, Stuart Henderson
() escribió:
>
> This diff adds something similar to cisco's ping display, giving a
> visual display of good/dropped pings. Any interest in it? Example
> output (with a couple of ^T during the run):
>
> $ ping -g 192.168.41.21
> PING 192.168.41.21 (192.168.41.21): 56 data bytes
> load:
> 0.04 cmd: ping 8312 [running] 0.00u 0.00s 0% 117k
>
> --- 192.168.41.21 ping statistics ---
> 212 packets transmitted, 212 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 0.342/0.636/28.579/1.940 ms
> .!!...!!!...!.!!!...!!!...!.!!!.....!.!!!.....!.!!!.....!!....!!....!!..!..load:
> 0.00 cmd: ping 8312 [running] 0.00u 0.00s 0% 118k
>
> --- 192.168.41.21 ping statistics ---
> 924 packets transmitted, 800 packets received, 13.4% packet loss
> round-trip min/avg/max/std-dev = 0.304/0.618/41.986/1.933 ms
>
> (and while I'm there, if anyone has an idea why this one machine being
> pinged, which is a 6.8 box with em(4), might periodically stop receiving
> packets from a couple of hosts in the subnet while things are working
> ok for others, I'm all ears ;) no interface errors, netlivelocks, etc.)
>
>
> Index: ping.8
> ===
> RCS file: /cvs/src/sbin/ping/ping.8,v
> retrieving revision 1.63
> diff -u -p -r1.63 ping.8
> --- ping.8 11 Feb 2020 18:41:39 - 1.63
> +++ ping.8 19 Feb 2021 15:11:19 -
> @@ -66,7 +66,7 @@
> .Nd send ICMP ECHO_REQUEST packets to network hosts
> .Sh SYNOPSIS
> .Nm ping
> -.Op Fl DdEefHLnqRv
> +.Op Fl DdEefgHLnqRv
> .Op Fl c Ar count
> .Op Fl I Ar sourceaddr
> .Op Fl i Ar interval
> @@ -79,7 +79,7 @@
> .Op Fl w Ar maxwait
> .Ar host
> .Nm ping6
> -.Op Fl DdEefHLmnqv
> +.Op Fl DdEefgHLmnqv
> .Op Fl c Ar count
> .Op Fl h Ar hoplimit
> .Op Fl I Ar sourceaddr
> @@ -151,6 +151,21 @@ Only the superuser may use this option.
> .Bf -emphasis
> This can be very hard on a network and should be used with caution.
> .Ef
> +.It Fl g
> +Graphic display.
> +This provides a quick visual display of packets received and lost.
> +For every
> +.Dv ECHO_REPLY
> +received, a period
> +.Sq \&.
> +is printed, while for every missed packet an exclamation mark
> +.Sq !
> +is printed.
> +Duplicate and truncated replies are indicated with
> +.Sq D
> +and
> +.Sq T
> +respectively.
> .It Fl H
> Try reverse lookups for addresses.
> .It Fl h Ar hoplimit
> Index: ping.c
> ===
> RCS file: /cvs/src/sbin/ping/ping.c,v
> retrieving revision 1.243
> diff -u -p -r1.243 ping.c
> --- ping.c 29 Dec 2020 16:40:47 - 1.243
> +++ ping.c 19 Feb 2021 15:11:19 -
> @@ -145,7 +145,7 @@ int options;
> #defineF_QUIET 0x0010
> #defineF_RROUTE0x0020
> #defineF_SO_DEBUG 0x0040
> -/* 0x0080 */
> +#defineF_GRAPHIC 0x0080
> #defineF_VERBOSE 0x0100
> /* 0x0200 */
> #defineF_HDRINCL 0x0400
> @@ -297,8 +297,8 @@ main(int argc, char *argv[])
> preload = 0;
> datap = [ECHOLEN + ECHOTMLEN];
> while ((ch = getopt(argc, argv, v6flag ?
> - "c:DdEefHh:I:i:Ll:mNnp:qS:s:T:V:vw:" :
> - "DEI:LRS:c:defHi:l:np:qs:T:t:V:vw:")) != -1) {
> + "c:DdEefgHh:I:i:Ll:mNnp:qS:s:T:V:vw:" :
> + "DEI:LRS:c:defgHi:l:np:qs:T:t:V:vw:")) != -1) {
> switch(ch) {
> case 'c':
> npackets = strtonum(optarg, 0, INT64_MAX, );
> @@ -326,6 +326,9 @@ main(int argc, char *argv[])
> options |= F_FLOOD;
> setvbuf(stdout, NULL, _IONBF, 0);
> break;
> + case 'g':
> + options |= F_GRAPHIC;
> + break;
> case 'H':
> options |= F_HOSTNAME;
> break;
> @@ -879,6 +882,11 @@ main(int argc, char
Re: occasional SSIGSEGV on C++ exception handling
On Fri, Feb 19, 2021 at 01:06:43PM +0100, Otto Moerbeek wrote:
> On Fri, Feb 19, 2021 at 12:45:58PM +0100, Mark Kettenis wrote:
>
> > > Date: Fri, 19 Feb 2021 10:57:30 +0100
> > > From: Otto Moerbeek
> > >
> > > Hi,
> > >
> > > working on PowerDNS Recursor, once in a while I'm seeing:
> > >
> > > #0 0x09fd67ef09dc in
> > > libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR
> > > (this=,
> > > head=0x9fd67efc8e8 , elm=0x9fca04be900)
> > > at
> > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
> > > 243 RB_GENERATE(CacheTree, CacheItem, entry, CacheCmp);
> > > [Current thread is 1 (process 349420)]
> > > (gdb) bt
> > > #0 0x09fd67ef09dc in
> > > libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR
> > > (this=,
> > > head=0x9fd67efc8e8 , elm=0x9fca04be900)
> > > at
> > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
> > > #1 0x09fd67eeddef in
> > > libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT
> > > (this=,
> > > head=, elm=)
> > > at
> > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
> > > #2 libunwind::UnwindInfoSectionsCache::setUnwindInfoSectionsForPC
> > > (this=, key=10983975073074,
> > > uis=...) at
> > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:237
> > > #3 libunwind::UnwindCursor > > libunwind::Registers_x86_64>::setInfoBasedOnIPRegister (
> > > this=0x9fd2ca0aa68, isReturnAddress=)
> > > at
> > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindCursor.hpp:1891
> > > #4 0x09fd67eedaa4 in
> > > libunwind::UnwindCursor > > libunwind::Registers_x86_64>::step (
> > > this=0x9fd2ca0aa68) at
> > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindCursor.hpp:2031
> > > #5 0x09fd67ef15a4 in unwind_phase1 (uc=,
> > > cursor=, exception_object=0x9fd37b24560)
> > > at
> > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindLevel1.c:46
> > > #6 _Unwind_RaiseException (exception_object=0x9fd37b24560)
> > > at
> > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindLevel1.c:363
> > > #7 0x09fd67eeb533 in __cxa_throw (thrown_object=0x9fd37b24580,
> > > tinfo=0x9fa6c615a00 , dest= > > out>)
> > > at
> > > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libcxxabi/src/cxa_exception.cpp:279
> > > #8 0x09fa6c295955 in ComboAddress::ComboAddress (this= > > out>, str=..., port=)
> > > at ./iputils.hh:219
> > > #9 0x09fa6c489970 in startFrameStreamServers (config=...) at
> > > pdns_recursor.cc:1248
> > > #10 checkFrameStreamExport (luaconfsLocal=...) at pdns_recursor.cc:1290
> > > #11 0x09fa6c48158f in recursorThread (n=,
> > > ...
> > >
> > > This does not happen always, most of the time this exception is
> > > handled correctly, afaik.
> > >
> > > The code that twrows an exception is:
> > > try {
> > > ComboAddress address(server);
> > > ...
> > > }
> > > catch ...
> > >
> > > The ComboAddress constructor throws the exception (and is supposed to
> > > do that). It looks like libunwind gets confused somehow.
> > >
> > > Any clue?
> >
> > The cache that pirofti@ added a while ago isn't thread-safe. Or maybe
> > this is a use-after free caused by dlcose(4). We should probably
> > disable/remove it while he is working on a better solution.
> > Unfortunately I don't think adding locking here is a good idea so this
> > may need a more fundamental rethink.
> >
> > Upstream did add an optimization in this area a few months ago:
> >
> >
> > https://github.com/llvm/llvm-project/commit/881aba7071c6e4cc2417e875ca5027ec7c0a92a3
> >
> > The version of libunwind we're using is older than that, so it may be
> > worth picking that up and see if that improves the original problem.
>
> First I'm going to try to fix it my making the cache thread_local.
>
> I'm probably going to regret looking at this code,
>
> -Otto
The diff below works for my test case on amd64.
It also feels right from a theoretical point of view. As for practical
matters, if thread local storage isn't working properly, a lot more
things would break. So I am a bit more optimisic about the diff now
than this morning.
So we have three options, I think:
- back the caching out,
- investigate the commit you mention above. Sadly I cannot
remember the original case that prompted for the caching code to be
added.
- continue on the thread_local path
We *have* to pick a solution. Having broken exception handling for
multi-threaded applications is no fun at all...
Otto
>
> Index: UnwindCursor.hpp
> ===
> RCS file: /cvs/src/gnu/llvm/libunwind/src/UnwindCursor.hpp,v
> retrieving revision 1.2
> diff -u -p -r1.2 UnwindCursor.hpp
> --- UnwindCursor.hpp
Re: ping graphical display
On Fri, Feb 19, 2021 at 03:19:49PM +, Stuart Henderson wrote: > This diff adds something similar to cisco's ping display, giving a > visual display of good/dropped pings. Any interest in it? Example > output (with a couple of ^T during the run): fwiw, noping from net/liboping in ports has this feature builtin. Landry
Re: ping graphical display
On 2021/02/19 15:19, Stuart Henderson wrote: > This diff adds something similar to cisco's ping display, giving a > visual display of good/dropped pings. Any interest in it? Example > output (with a couple of ^T during the run): (as is traditional I forgot to update usage(), I've fixed that locally)
ping graphical display
This diff adds something similar to cisco's ping display, giving a
visual display of good/dropped pings. Any interest in it? Example
output (with a couple of ^T during the run):
$ ping -g 192.168.41.21
PING 192.168.41.21 (192.168.41.21): 56 data bytes
load:
0.04 cmd: ping 8312 [running] 0.00u 0.00s 0% 117k
--- 192.168.41.21 ping statistics ---
212 packets transmitted, 212 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.342/0.636/28.579/1.940 ms
.!!...!!!...!.!!!...!!!...!.!!!.....!.!!!.....!.!!!.....!!....!!....!!..!..load:
0.00 cmd: ping 8312 [running] 0.00u 0.00s 0% 118k
--- 192.168.41.21 ping statistics ---
924 packets transmitted, 800 packets received, 13.4% packet loss
round-trip min/avg/max/std-dev = 0.304/0.618/41.986/1.933 ms
(and while I'm there, if anyone has an idea why this one machine being
pinged, which is a 6.8 box with em(4), might periodically stop receiving
packets from a couple of hosts in the subnet while things are working
ok for others, I'm all ears ;) no interface errors, netlivelocks, etc.)
Index: ping.8
===
RCS file: /cvs/src/sbin/ping/ping.8,v
retrieving revision 1.63
diff -u -p -r1.63 ping.8
--- ping.8 11 Feb 2020 18:41:39 - 1.63
+++ ping.8 19 Feb 2021 15:11:19 -
@@ -66,7 +66,7 @@
.Nd send ICMP ECHO_REQUEST packets to network hosts
.Sh SYNOPSIS
.Nm ping
-.Op Fl DdEefHLnqRv
+.Op Fl DdEefgHLnqRv
.Op Fl c Ar count
.Op Fl I Ar sourceaddr
.Op Fl i Ar interval
@@ -79,7 +79,7 @@
.Op Fl w Ar maxwait
.Ar host
.Nm ping6
-.Op Fl DdEefHLmnqv
+.Op Fl DdEefgHLmnqv
.Op Fl c Ar count
.Op Fl h Ar hoplimit
.Op Fl I Ar sourceaddr
@@ -151,6 +151,21 @@ Only the superuser may use this option.
.Bf -emphasis
This can be very hard on a network and should be used with caution.
.Ef
+.It Fl g
+Graphic display.
+This provides a quick visual display of packets received and lost.
+For every
+.Dv ECHO_REPLY
+received, a period
+.Sq \&.
+is printed, while for every missed packet an exclamation mark
+.Sq !
+is printed.
+Duplicate and truncated replies are indicated with
+.Sq D
+and
+.Sq T
+respectively.
.It Fl H
Try reverse lookups for addresses.
.It Fl h Ar hoplimit
Index: ping.c
===
RCS file: /cvs/src/sbin/ping/ping.c,v
retrieving revision 1.243
diff -u -p -r1.243 ping.c
--- ping.c 29 Dec 2020 16:40:47 - 1.243
+++ ping.c 19 Feb 2021 15:11:19 -
@@ -145,7 +145,7 @@ int options;
#defineF_QUIET 0x0010
#defineF_RROUTE0x0020
#defineF_SO_DEBUG 0x0040
-/* 0x0080 */
+#defineF_GRAPHIC 0x0080
#defineF_VERBOSE 0x0100
/* 0x0200 */
#defineF_HDRINCL 0x0400
@@ -297,8 +297,8 @@ main(int argc, char *argv[])
preload = 0;
datap = [ECHOLEN + ECHOTMLEN];
while ((ch = getopt(argc, argv, v6flag ?
- "c:DdEefHh:I:i:Ll:mNnp:qS:s:T:V:vw:" :
- "DEI:LRS:c:defHi:l:np:qs:T:t:V:vw:")) != -1) {
+ "c:DdEefgHh:I:i:Ll:mNnp:qS:s:T:V:vw:" :
+ "DEI:LRS:c:defgHi:l:np:qs:T:t:V:vw:")) != -1) {
switch(ch) {
case 'c':
npackets = strtonum(optarg, 0, INT64_MAX, );
@@ -326,6 +326,9 @@ main(int argc, char *argv[])
options |= F_FLOOD;
setvbuf(stdout, NULL, _IONBF, 0);
break;
+ case 'g':
+ options |= F_GRAPHIC;
+ break;
case 'H':
options |= F_HOSTNAME;
break;
@@ -879,6 +882,11 @@ main(int argc, char *argv[])
if (!(options & F_FLOOD) &&
(options & F_AUD_MISS))
fputc('\a', stderr);
+ if ((options & F_GRAPHIC) &&
+ !(options & F_FLOOD)) {
+ putchar('!');
+
Re: Secure by default
On 2021/02/19 20:27, sivasubramanian muthusamy wrote: > Dear Flint, > > During installation I didn't connect the network, but after installation, > Yes. What would I do with a Computer that isn't connected? My use case is > all about Internet :) Other use cases are available.
Re: Secure by default
Dear Flint, During installation I didn't connect the network, but after installation, Yes. What would I do with a Computer that isn't connected? My use case is all about Internet :) On Sun, Feb 14, 2021, 02:49 flint pyrite wrote: > I am not sure about your use case but to myself, my computer is useless > these days without a connection. > > > On Sat, Feb 13, 2021 at 1:15 PM sivasubramanian muthusamy < > 6.inter...@gmail.com> wrote: > >> Hello, >> >> I am an ordinary computer user, installed 6.8 without connecting to >> the Internet yet, (a friend and a technical expert recently advised me >> in a different context: do not expose your machine to the Internet- >> don't know what that means) >> >> OpenBSD intro says OpenBSD is secure by default. How is it secure by >> default for an average user who does not get to ssh, does not use his >> computer as a web-server or as a VM host, who does not have to share >> screen etc? What ports are open by default and what applications start >> by default? >> >> Before connecting the computer to the Internet, what other steps >> should a very ordinary user take? Block a few more ports? Which ones? >> >> Thank you. >> >> Sivasubramanian M >> >>
Re: occasional SSIGSEGV on C++ exception handling
On Fri, Feb 19, 2021 at 12:45:58PM +0100, Mark Kettenis wrote:
> > Date: Fri, 19 Feb 2021 10:57:30 +0100
> > From: Otto Moerbeek
> >
> > Hi,
> >
> > working on PowerDNS Recursor, once in a while I'm seeing:
> >
> > #0 0x09fd67ef09dc in
> > libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR
> > (this=,
> > head=0x9fd67efc8e8 , elm=0x9fca04be900)
> > at
> > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
> > 243 RB_GENERATE(CacheTree, CacheItem, entry, CacheCmp);
> > [Current thread is 1 (process 349420)]
> > (gdb) bt
> > #0 0x09fd67ef09dc in
> > libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR
> > (this=,
> > head=0x9fd67efc8e8 , elm=0x9fca04be900)
> > at
> > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
> > #1 0x09fd67eeddef in
> > libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT
> > (this=,
> > head=, elm=)
> > at
> > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
> > #2 libunwind::UnwindInfoSectionsCache::setUnwindInfoSectionsForPC
> > (this=, key=10983975073074,
> > uis=...) at
> > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:237
> > #3 libunwind::UnwindCursor > libunwind::Registers_x86_64>::setInfoBasedOnIPRegister (
> > this=0x9fd2ca0aa68, isReturnAddress=)
> > at
> > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindCursor.hpp:1891
> > #4 0x09fd67eedaa4 in
> > libunwind::UnwindCursor > libunwind::Registers_x86_64>::step (
> > this=0x9fd2ca0aa68) at
> > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindCursor.hpp:2031
> > #5 0x09fd67ef15a4 in unwind_phase1 (uc=,
> > cursor=, exception_object=0x9fd37b24560)
> > at
> > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindLevel1.c:46
> > #6 _Unwind_RaiseException (exception_object=0x9fd37b24560)
> > at
> > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindLevel1.c:363
> > #7 0x09fd67eeb533 in __cxa_throw (thrown_object=0x9fd37b24580,
> > tinfo=0x9fa6c615a00 , dest=)
> > at
> > /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libcxxabi/src/cxa_exception.cpp:279
> > #8 0x09fa6c295955 in ComboAddress::ComboAddress (this= > out>, str=..., port=)
> > at ./iputils.hh:219
> > #9 0x09fa6c489970 in startFrameStreamServers (config=...) at
> > pdns_recursor.cc:1248
> > #10 checkFrameStreamExport (luaconfsLocal=...) at pdns_recursor.cc:1290
> > #11 0x09fa6c48158f in recursorThread (n=,
> > ...
> >
> > This does not happen always, most of the time this exception is
> > handled correctly, afaik.
> >
> > The code that twrows an exception is:
> > try {
> > ComboAddress address(server);
> > ...
> > }
> > catch ...
> >
> > The ComboAddress constructor throws the exception (and is supposed to
> > do that). It looks like libunwind gets confused somehow.
> >
> > Any clue?
>
> The cache that pirofti@ added a while ago isn't thread-safe. Or maybe
> this is a use-after free caused by dlcose(4). We should probably
> disable/remove it while he is working on a better solution.
> Unfortunately I don't think adding locking here is a good idea so this
> may need a more fundamental rethink.
>
> Upstream did add an optimization in this area a few months ago:
>
>
> https://github.com/llvm/llvm-project/commit/881aba7071c6e4cc2417e875ca5027ec7c0a92a3
>
> The version of libunwind we're using is older than that, so it may be
> worth picking that up and see if that improves the original problem.
First I'm going to try to fix it my making the cache thread_local.
I'm probably going to regret looking at this code,
-Otto
Index: UnwindCursor.hpp
===
RCS file: /cvs/src/gnu/llvm/libunwind/src/UnwindCursor.hpp,v
retrieving revision 1.2
diff -u -p -r1.2 UnwindCursor.hpp
--- UnwindCursor.hpp2 Jan 2021 01:10:02 - 1.2
+++ UnwindCursor.hpp19 Feb 2021 12:05:26 -
@@ -75,7 +75,7 @@ extern "C" _Unwind_Reason_Code __libunwi
namespace libunwind {
-static UnwindInfoSectionsCache uwis_cache;
+static thread_local UnwindInfoSectionsCache uwis_cache;
#if defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND)
/// Cache of recently found FDEs.
Re: occasional SSIGSEGV on C++ exception handling
> Date: Fri, 19 Feb 2021 10:57:30 +0100
> From: Otto Moerbeek
>
> Hi,
>
> working on PowerDNS Recursor, once in a while I'm seeing:
>
> #0 0x09fd67ef09dc in
> libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR
> (this=,
> head=0x9fd67efc8e8 , elm=0x9fca04be900)
> at
> /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
> 243 RB_GENERATE(CacheTree, CacheItem, entry, CacheCmp);
> [Current thread is 1 (process 349420)]
> (gdb) bt
> #0 0x09fd67ef09dc in
> libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR
> (this=,
> head=0x9fd67efc8e8 , elm=0x9fca04be900)
> at
> /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
> #1 0x09fd67eeddef in
> libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT
> (this=,
> head=, elm=)
> at
> /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
> #2 libunwind::UnwindInfoSectionsCache::setUnwindInfoSectionsForPC
> (this=, key=10983975073074,
> uis=...) at
> /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:237
> #3 libunwind::UnwindCursor libunwind::Registers_x86_64>::setInfoBasedOnIPRegister (
> this=0x9fd2ca0aa68, isReturnAddress=)
> at
> /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindCursor.hpp:1891
> #4 0x09fd67eedaa4 in
> libunwind::UnwindCursor libunwind::Registers_x86_64>::step (
> this=0x9fd2ca0aa68) at
> /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindCursor.hpp:2031
> #5 0x09fd67ef15a4 in unwind_phase1 (uc=,
> cursor=, exception_object=0x9fd37b24560)
> at
> /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindLevel1.c:46
> #6 _Unwind_RaiseException (exception_object=0x9fd37b24560)
> at
> /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindLevel1.c:363
> #7 0x09fd67eeb533 in __cxa_throw (thrown_object=0x9fd37b24580,
> tinfo=0x9fa6c615a00 , dest=)
> at
> /usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libcxxabi/src/cxa_exception.cpp:279
> #8 0x09fa6c295955 in ComboAddress::ComboAddress (this= out>, str=..., port=)
> at ./iputils.hh:219
> #9 0x09fa6c489970 in startFrameStreamServers (config=...) at
> pdns_recursor.cc:1248
> #10 checkFrameStreamExport (luaconfsLocal=...) at pdns_recursor.cc:1290
> #11 0x09fa6c48158f in recursorThread (n=,
> ...
>
> This does not happen always, most of the time this exception is
> handled correctly, afaik.
>
> The code that twrows an exception is:
> try {
> ComboAddress address(server);
> ...
> }
> catch ...
>
> The ComboAddress constructor throws the exception (and is supposed to
> do that). It looks like libunwind gets confused somehow.
>
> Any clue?
The cache that pirofti@ added a while ago isn't thread-safe. Or maybe
this is a use-after free caused by dlcose(4). We should probably
disable/remove it while he is working on a better solution.
Unfortunately I don't think adding locking here is a good idea so this
may need a more fundamental rethink.
Upstream did add an optimization in this area a few months ago:
https://github.com/llvm/llvm-project/commit/881aba7071c6e4cc2417e875ca5027ec7c0a92a3
The version of libunwind we're using is older than that, so it may be
worth picking that up and see if that improves the original problem.
Re: rpki-client extra paranoia
On Fri, Feb 19, 2021 at 10:54:29AM +0100, Claudio Jeker wrote:
> Better to make sure that all URI we ingest are sensitive. Similar check
> is already done in cert.c so also do it for the TAL files (even though
> these are normally controled by the user).
>
> OK?
ok
> --
> :wq Claudio
>
> Index: tal.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/tal.c,v
> retrieving revision 1.26
> diff -u -p -r1.26 tal.c
> --- tal.c 8 Jan 2021 08:09:07 - 1.26
> +++ tal.c 19 Feb 2021 09:21:18 -
> @@ -82,6 +82,7 @@ tal_parse_buffer(const char *fn, char *b
> char*nl, *line, *f, *file = NULL;
> unsigned char *der;
> size_t sz, dersz;
> + ssize_t i;
> int rc = 0;
> struct tal *tal = NULL;
> EVP_PKEY*pkey = NULL;
> @@ -101,6 +102,13 @@ tal_parse_buffer(const char *fn, char *b
> if (*line == '\0')
> break;
>
> + /* make sure only US-ASCII chars are in the URL */
> + for (i = 0; i < nl - line; i++) {
> + if (isalnum(line[i]) || ispunct(line[i]))
> + continue;
> + warnx("%s: invalid URI", fn);
> + goto out;
> + }
> /* Check that the URI is sensible */
> if (!(strncasecmp(line, "https://;, 8) == 0 ||
> strncasecmp(line, "rsync://", 8) == 0)) {
>
occasional SSIGSEGV on C++ exception handling
Hi,
working on PowerDNS Recursor, once in a while I'm seeing:
#0 0x09fd67ef09dc in
libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR
(this=,
head=0x9fd67efc8e8 , elm=0x9fca04be900)
at
/usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
243 RB_GENERATE(CacheTree, CacheItem, entry, CacheCmp);
[Current thread is 1 (process 349420)]
(gdb) bt
#0 0x09fd67ef09dc in
libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT_COLOR
(this=,
head=0x9fd67efc8e8 , elm=0x9fca04be900)
at
/usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
#1 0x09fd67eeddef in
libunwind::UnwindInfoSectionsCache::CacheTree_RB_INSERT
(this=,
head=, elm=)
at
/usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:243
#2 libunwind::UnwindInfoSectionsCache::setUnwindInfoSectionsForPC
(this=, key=10983975073074,
uis=...) at
/usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/AddressSpace.hpp:237
#3 libunwind::UnwindCursor::setInfoBasedOnIPRegister (
this=0x9fd2ca0aa68, isReturnAddress=)
at
/usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindCursor.hpp:1891
#4 0x09fd67eedaa4 in
libunwind::UnwindCursor::step (
this=0x9fd2ca0aa68) at
/usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindCursor.hpp:2031
#5 0x09fd67ef15a4 in unwind_phase1 (uc=,
cursor=, exception_object=0x9fd37b24560)
at
/usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindLevel1.c:46
#6 _Unwind_RaiseException (exception_object=0x9fd37b24560)
at
/usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libunwind/src/UnwindLevel1.c:363
#7 0x09fd67eeb533 in __cxa_throw (thrown_object=0x9fd37b24580,
tinfo=0x9fa6c615a00 , dest=)
at
/usr/src/gnu/lib/libcxxabi/../../../gnu/llvm/libcxxabi/src/cxa_exception.cpp:279
#8 0x09fa6c295955 in ComboAddress::ComboAddress (this=, str=..., port=)
at ./iputils.hh:219
#9 0x09fa6c489970 in startFrameStreamServers (config=...) at
pdns_recursor.cc:1248
#10 checkFrameStreamExport (luaconfsLocal=...) at pdns_recursor.cc:1290
#11 0x09fa6c48158f in recursorThread (n=,
...
This does not happen always, most of the time this exception is
handled correctly, afaik.
The code that twrows an exception is:
try {
ComboAddress address(server);
...
}
catch ...
The ComboAddress constructor throws the exception (and is supposed to
do that). It looks like libunwind gets confused somehow.
Any clue?
-Otto
rpki-client extra paranoia
Better to make sure that all URI we ingest are sensitive. Similar check
is already done in cert.c so also do it for the TAL files (even though
these are normally controled by the user).
OK?
--
:wq Claudio
Index: tal.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/tal.c,v
retrieving revision 1.26
diff -u -p -r1.26 tal.c
--- tal.c 8 Jan 2021 08:09:07 - 1.26
+++ tal.c 19 Feb 2021 09:21:18 -
@@ -82,6 +82,7 @@ tal_parse_buffer(const char *fn, char *b
char*nl, *line, *f, *file = NULL;
unsigned char *der;
size_t sz, dersz;
+ ssize_t i;
int rc = 0;
struct tal *tal = NULL;
EVP_PKEY*pkey = NULL;
@@ -101,6 +102,13 @@ tal_parse_buffer(const char *fn, char *b
if (*line == '\0')
break;
+ /* make sure only US-ASCII chars are in the URL */
+ for (i = 0; i < nl - line; i++) {
+ if (isalnum(line[i]) || ispunct(line[i]))
+ continue;
+ warnx("%s: invalid URI", fn);
+ goto out;
+ }
/* Check that the URI is sensible */
if (!(strncasecmp(line, "https://;, 8) == 0 ||
strncasecmp(line, "rsync://", 8) == 0)) {
Re: rpki-client: recallocarray conversions
On Fri, Feb 19, 2021 at 10:27:06AM +0100, Theo Buehler wrote:
> As discussed a few days ago, there are a few reallocarray + memset that
> can be directly handled by recallocarray.
Fine with me.
> Index: main.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
> retrieving revision 1.101
> diff -u -p -r1.101 main.c
> --- main.c18 Feb 2021 10:10:20 - 1.101
> +++ main.c19 Feb 2021 08:56:19 -
> @@ -265,12 +265,12 @@ repo_alloc(void)
> {
> struct repo *rp;
>
> - rt.repos = reallocarray(rt.repos, rt.reposz + 1, sizeof(struct repo));
> + rt.repos = recallocarray(rt.repos, rt.reposz, rt.reposz + 1,
> + sizeof(struct repo));
> if (rt.repos == NULL)
> - err(1, "reallocarray");
> + err(1, "recallocarray");
>
> rp = [rt.reposz++];
> - memset(rp, 0, sizeof(struct repo));
> rp->id = rt.reposz - 1;
>
> return rp;
> Index: mft.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/mft.c,v
> retrieving revision 1.26
> diff -u -p -r1.26 mft.c
> --- mft.c 16 Feb 2021 07:58:30 - 1.26
> +++ mft.c 19 Feb 2021 07:04:25 -
> @@ -193,13 +193,12 @@ mft_parse_filehash(struct parse *p, cons
>
> /* Insert the filename and hash value. */
>
> - p->res->files = reallocarray(p->res->files, p->res->filesz + 1,
> - sizeof(struct mftfile));
> + p->res->files = recallocarray(p->res->files, p->res->filesz,
> + p->res->filesz + 1, sizeof(struct mftfile));
> if (p->res->files == NULL)
> err(1, NULL);
>
> fent = >res->files[p->res->filesz++];
> - memset(fent, 0, sizeof(struct mftfile));
>
> fent->file = fn;
> fn = NULL;
> Index: roa.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/roa.c,v
> retrieving revision 1.14
> diff -u -p -r1.14 roa.c
> --- roa.c 16 Feb 2021 07:58:30 - 1.14
> +++ roa.c 19 Feb 2021 07:07:30 -
> @@ -111,12 +111,11 @@ roa_parse_addr(const ASN1_OCTET_STRING *
> /* FIXME: maximum check. */
> }
>
> - p->res->ips = reallocarray(p->res->ips,
> - p->res->ipsz + 1, sizeof(struct roa_ip));
> + p->res->ips = recallocarray(p->res->ips, p->res->ipsz, p->res->ipsz + 1,
> + sizeof(struct roa_ip));
> if (p->res->ips == NULL)
> err(1, NULL);
> res = >res->ips[p->res->ipsz++];
> - memset(res, 0, sizeof(struct roa_ip));
>
> res->addr = addr;
> res->afi = afi;
>
--
:wq Claudio
Re: relayd check script memory explosion
On Mon, Feb 15, 2021 at 12:03:42PM +1000, Jonathan Matthew wrote:
> It's fairly easy to accidentally configure relayd to try to run check scripts
> faster than they finish, for example if you have a check interval of one
> second and the check script makes a tcp connection to a host that doesn't
> exist any more.
>
> In this situation, the hce process will keep writing messages to its imsg
> buffer to the parent process asking it to run checks, which causes its memory
> usage to grow without bounds. If the check script starts working again
> (or if you change it to just 'exit 0') the parent works its way through the
> backlog and memory usage goes back to normal, but ideally relayd would avoid
> doing this to itself.
>
> If we don't clear the F_CHECK_SENT and F_CHECK_DONE flags in
> hce_launch_checks(), check_script() can use them to figure out if the
> last check request it sent for the host has finished yet, so it can avoid
> building up a backlog of work for the parent. The ICMP and script check
> implementations clear these flags as they start checks, and the TCP check
> code doesn't use them at all, so this shouldn't affect anything else.
>
> ok?
ok tb
>
>
> Index: check_script.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/check_script.c,v
> retrieving revision 1.21
> diff -u -p -u -p -r1.21 check_script.c
> --- check_script.c28 May 2017 10:39:15 - 1.21
> +++ check_script.c15 Feb 2021 01:28:54 -
> @@ -38,6 +38,9 @@ check_script(struct relayd *env, struct
> struct ctl_scriptscr;
> struct table*table;
>
> + if ((host->flags & (F_CHECK_SENT|F_CHECK_DONE)) == F_CHECK_SENT)
> + return;
> +
> if ((table = table_find(env, host->conf.tableid)) == NULL)
> fatalx("%s: invalid table id", __func__);
>
> @@ -52,7 +55,9 @@ check_script(struct relayd *env, struct
> fatalx("invalid script path");
> memcpy(, >conf.timeout, sizeof(scr.timeout));
>
> - proc_compose(env->sc_ps, PROC_PARENT, IMSG_SCRIPT, , sizeof(scr));
> + if (proc_compose(env->sc_ps, PROC_PARENT, IMSG_SCRIPT, ,
> + sizeof(scr)) == 0)
> + host->flags |= F_CHECK_SENT;
> }
>
> void
> Index: hce.c
> ===
> RCS file: /cvs/src/usr.sbin/relayd/hce.c,v
> retrieving revision 1.79
> diff -u -p -u -p -r1.79 hce.c
> --- hce.c 6 Aug 2018 17:31:31 - 1.79
> +++ hce.c 15 Feb 2021 01:28:54 -
> @@ -139,7 +139,6 @@ hce_launch_checks(int fd, short event, v
> TAILQ_FOREACH(host, >hosts, entry) {
> if ((host->flags & F_CHECK_DONE) == 0)
> host->he = HCE_INTERVAL_TIMEOUT;
> - host->flags &= ~(F_CHECK_SENT|F_CHECK_DONE);
> if (event_initialized(>cte.ev)) {
> event_del(>cte.ev);
> close(host->cte.s);
>
rpki-client: recallocarray conversions
As discussed a few days ago, there are a few reallocarray + memset that
can be directly handled by recallocarray.
Index: main.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/main.c,v
retrieving revision 1.101
diff -u -p -r1.101 main.c
--- main.c 18 Feb 2021 10:10:20 - 1.101
+++ main.c 19 Feb 2021 08:56:19 -
@@ -265,12 +265,12 @@ repo_alloc(void)
{
struct repo *rp;
- rt.repos = reallocarray(rt.repos, rt.reposz + 1, sizeof(struct repo));
+ rt.repos = recallocarray(rt.repos, rt.reposz, rt.reposz + 1,
+ sizeof(struct repo));
if (rt.repos == NULL)
- err(1, "reallocarray");
+ err(1, "recallocarray");
rp = [rt.reposz++];
- memset(rp, 0, sizeof(struct repo));
rp->id = rt.reposz - 1;
return rp;
Index: mft.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/mft.c,v
retrieving revision 1.26
diff -u -p -r1.26 mft.c
--- mft.c 16 Feb 2021 07:58:30 - 1.26
+++ mft.c 19 Feb 2021 07:04:25 -
@@ -193,13 +193,12 @@ mft_parse_filehash(struct parse *p, cons
/* Insert the filename and hash value. */
- p->res->files = reallocarray(p->res->files, p->res->filesz + 1,
- sizeof(struct mftfile));
+ p->res->files = recallocarray(p->res->files, p->res->filesz,
+ p->res->filesz + 1, sizeof(struct mftfile));
if (p->res->files == NULL)
err(1, NULL);
fent = >res->files[p->res->filesz++];
- memset(fent, 0, sizeof(struct mftfile));
fent->file = fn;
fn = NULL;
Index: roa.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/roa.c,v
retrieving revision 1.14
diff -u -p -r1.14 roa.c
--- roa.c 16 Feb 2021 07:58:30 - 1.14
+++ roa.c 19 Feb 2021 07:07:30 -
@@ -111,12 +111,11 @@ roa_parse_addr(const ASN1_OCTET_STRING *
/* FIXME: maximum check. */
}
- p->res->ips = reallocarray(p->res->ips,
- p->res->ipsz + 1, sizeof(struct roa_ip));
+ p->res->ips = recallocarray(p->res->ips, p->res->ipsz, p->res->ipsz + 1,
+ sizeof(struct roa_ip));
if (p->res->ips == NULL)
err(1, NULL);
res = >res->ips[p->res->ipsz++];
- memset(res, 0, sizeof(struct roa_ip));
res->addr = addr;
res->afi = afi;
