Re: ospfd: prevent additional ospfd from starting
On Mon, Aug 27, 2018 at 11:33:19PM +0200, Remi Locherer wrote: > On Fri, Aug 24, 2018 at 12:21:31PM +0200, Remi Locherer wrote: > > On Fri, Aug 24, 2018 at 08:58:12AM +0200, Claudio Jeker wrote: > > > On Wed, Aug 22, 2018 at 12:12:10AM +0200, Remi Locherer wrote: > > > > On Tue, Aug 21, 2018 at 05:54:18PM +0100, Stuart Henderson wrote: > > > > > On 2018/08/21 17:16, Remi Locherer wrote: > > > > > > Hi tech, > > > > > > > > > > > > recently we had a short outage in our network. A script started an > > > > > > additional > > > > > > ospfd instance because the -n flag for config test was missing. > > > > > > > > > > This is a problem with bgpd as well, last time I did this it killed > > > > > one of the > > > > > *other* routers on the network (i.e. not just the one where I > > > > > accidentally ran > > > > > 2x bgpd...). > > > > > > > > > > > What then happend was not nice: > > > > > > - The new ospfd unlinked the control socket of the first ospfd > > > > > > - The new ospfd removed all routes from the first ospfd > > > > > > - The new ospfd was not able to build up an adjacency and therefore > > > > > > could > > > > > > not install the routes needed for a recovery. > > > > > > - Both ospfd instances were running but non-functional. > > > > > > > > > > > > Of course the faulty script is fixed by now. ;-) > > > > > > > > > > > > It would be nice if ospfd could prevent such a situation. > > > > > > > > > > > > Below diff does these things: > > > > > > - Detect a running ospfd by first doing a connect on the control > > > > > > socket. > > > > > > - Do not delete the control socket on exit. > > > > > > - This could delete the socket of another instance. > > > > > > - Unlinking the socket on shutdown will be in the way once we add > > > > > > pledge > > > > > > to the main process. It was removed recently from various > > > > > > daemons. > > > > > > > > > > This all sounds very sensible. > > > > > > > > > > > - Do not delete routes added by another process even if they have > > > > > > prio RTP_OSPF. Without this the new ospfd will remove all the > > > > > > routes > > > > > > of the first one. > > > > > > > > > > I'm unsure about this, the above changes stop the new ospfd from > > > > > running > > > > > don't they, so that shouldn't be a problem? > > > > > > > > It stops to late. kr_init happens before and kill all existing routes > > > > with > > > > priority 32. And again in the shutdown function of ospfd. > > > > > > > > > > If an ospfd blows up for whatever reason, it would be quite > > > > > inconvenient > > > > > if it needs manual route tweaks rather than just 'rcctl start ospfd' > > > > > to fix it .. > > > > > > > > Yes, this is not optimal. > > > > > > > > The new diff below defers kr_init until the ospf engine notifies the > > > > parent > > > > that the control socket is ready. In case the ospf engine exits because > > > > the > > > > control socket is already in use no routes are known that could be > > > > removed. > > > > > > > > With this ospfd keeps the behaviour of removing foreign routes with > > > > priority 32. > > > > > > > > Better? > > > > > > > > > > Why are we not checking the control socket in the parent? > > > Also it may be better to create the control socket in the parent and pass > > > it to the ospfe. This is what bgpd is doing and allows to change the path > > > during runtime with a config reload. > > > > This makes sense to me. I'll come up with a new diff once I found some > > time for it. > > > > But I'm not sure about changing the socket path with a reload. I plan to > > pledge (stdio rpath sendfd wroute) and eventually unveil (read ospfd.conf) > > the main process. > > New diff below creates the control socket in the main process and passes it > to the ospf engine later on. The connect check on the control socket now > happens very early. > > The diff in action looks like this: > > typhoon ..sbin/ospfd$ doas obj/ospfd -dv > startup > control_init: socket in use > fatal in ospfd: control socket setup failed > typhoon 1 ..sbin/ospfd$ > > > I borrowed the fd passing code from slaacd. > > > > > > > > > Could there be a case where this causes ospfd to hang on start in the > > > connect? Not sure if we can sleep doing a connect() to a AF_UNIX socket. > > I never observed a hangin ospfctl which also does a connect on the control > socket. But I could not find the definitiv answer. > > Remi > > > Index: control.c > === > RCS file: /cvs/src/usr.sbin/ospfd/control.c,v > retrieving revision 1.44 > diff -u -p -r1.44 control.c > --- control.c 24 Jan 2017 04:24:25 - 1.44 > +++ control.c 27 Aug 2018 21:17:42 - > @@ -42,19 +42,29 @@ int > control_init(char *path) > { > struct sockaddr_un sun; > - int fd; > + int fd, fd_check; > mode_t old_umask; > > + bzero
nits in ifconfig.8
Hi, just a couple of nits in ifconfig.8 that I found whilst struggling to get a route to fe80::1 on a VPS. 'colon-separated' and 'comma-separated' is in keeping with the style of the rest of the page. 'lowest 64th bit' > 'lowest 64 bits' is self-explanatory, I hope. Index: ifconfig.8 === RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.317 diff -u -p -r1.317 ifconfig.8 --- ifconfig.8 13 Aug 2018 05:54:13 - 1.317 +++ ifconfig.8 28 Aug 2018 03:00:39 - @@ -122,7 +122,7 @@ a host name present in the host name dat .Xr hosts 5 ; .Dq dot notation (IPv4); -colon separated (IPv6); +colon-separated (IPv6); or CIDR notation. .It Ar dest_address Specify the address of the correspondent on the other end @@ -838,7 +838,7 @@ and Create a load balancing group consisting of up to 32 nodes. Each node is specified as a .Ar vhid:advskew -tuple in a comma separated list. +tuple in a comma-separated list. .It Cm carpdev Ar iface Attach to parent interface .Ar iface . @@ -1217,7 +1217,7 @@ Currently configured addresses will not invalid. .It Cm eui64 Fill the interface index -.Pq the lowermost 64th bit of an IPv6 address +.Pq the lowermost 64 bits of an IPv6 address automatically. .It Cm pltime Ar n Set preferred lifetime for the address, in seconds.
openssl s_time: drop SSLv2, SSLv3 APIs and symbols
If I understand correctly it is now impossible for the openssl(1) tool to open an SSLv2 or SSLv3 session with the host. We can also switch SSLv23_client_method to TLS_client_method to set a good example. ok? Index: s_time.c === RCS file: /cvs/src/usr.bin/openssl/s_time.c,v retrieving revision 1.30 diff -u -p -r1.30 s_time.c --- s_time.c28 Aug 2018 02:14:22 - 1.30 +++ s_time.c28 Aug 2018 02:21:25 - @@ -242,7 +242,7 @@ s_time_main(int argc, char **argv) } } - s_time_meth = SSLv23_client_method(); + s_time_meth = TLS_client_method(); verify_depth = 0; @@ -435,10 +435,6 @@ benchmark(int reuse_session) ver = SSL_version(scon); if (ver == TLS1_VERSION) ver = 't'; - else if (ver == SSL3_VERSION) - ver = '3'; - else if (ver == SSL2_VERSION) - ver = '2'; else ver = '*'; }
Re: ospfd: prevent additional ospfd from starting
On Fri, Aug 24, 2018 at 12:21:31PM +0200, Remi Locherer wrote: > On Fri, Aug 24, 2018 at 08:58:12AM +0200, Claudio Jeker wrote: > > On Wed, Aug 22, 2018 at 12:12:10AM +0200, Remi Locherer wrote: > > > On Tue, Aug 21, 2018 at 05:54:18PM +0100, Stuart Henderson wrote: > > > > On 2018/08/21 17:16, Remi Locherer wrote: > > > > > Hi tech, > > > > > > > > > > recently we had a short outage in our network. A script started an > > > > > additional > > > > > ospfd instance because the -n flag for config test was missing. > > > > > > > > This is a problem with bgpd as well, last time I did this it killed one > > > > of the > > > > *other* routers on the network (i.e. not just the one where I > > > > accidentally ran > > > > 2x bgpd...). > > > > > > > > > What then happend was not nice: > > > > > - The new ospfd unlinked the control socket of the first ospfd > > > > > - The new ospfd removed all routes from the first ospfd > > > > > - The new ospfd was not able to build up an adjacency and therefore > > > > > could > > > > > not install the routes needed for a recovery. > > > > > - Both ospfd instances were running but non-functional. > > > > > > > > > > Of course the faulty script is fixed by now. ;-) > > > > > > > > > > It would be nice if ospfd could prevent such a situation. > > > > > > > > > > Below diff does these things: > > > > > - Detect a running ospfd by first doing a connect on the control > > > > > socket. > > > > > - Do not delete the control socket on exit. > > > > > - This could delete the socket of another instance. > > > > > - Unlinking the socket on shutdown will be in the way once we add > > > > > pledge > > > > > to the main process. It was removed recently from various daemons. > > > > > > > > This all sounds very sensible. > > > > > > > > > - Do not delete routes added by another process even if they have > > > > > prio RTP_OSPF. Without this the new ospfd will remove all the routes > > > > > of the first one. > > > > > > > > I'm unsure about this, the above changes stop the new ospfd from running > > > > don't they, so that shouldn't be a problem? > > > > > > It stops to late. kr_init happens before and kill all existing routes with > > > priority 32. And again in the shutdown function of ospfd. > > > > > > > > If an ospfd blows up for whatever reason, it would be quite inconvenient > > > > if it needs manual route tweaks rather than just 'rcctl start ospfd' to > > > > fix it .. > > > > > > Yes, this is not optimal. > > > > > > The new diff below defers kr_init until the ospf engine notifies the > > > parent > > > that the control socket is ready. In case the ospf engine exits because > > > the > > > control socket is already in use no routes are known that could be > > > removed. > > > > > > With this ospfd keeps the behaviour of removing foreign routes with > > > priority 32. > > > > > > Better? > > > > > > > Why are we not checking the control socket in the parent? > > Also it may be better to create the control socket in the parent and pass > > it to the ospfe. This is what bgpd is doing and allows to change the path > > during runtime with a config reload. > > This makes sense to me. I'll come up with a new diff once I found some > time for it. > > But I'm not sure about changing the socket path with a reload. I plan to > pledge (stdio rpath sendfd wroute) and eventually unveil (read ospfd.conf) > the main process. New diff below creates the control socket in the main process and passes it to the ospf engine later on. The connect check on the control socket now happens very early. The diff in action looks like this: typhoon ..sbin/ospfd$ doas obj/ospfd -dv startup control_init: socket in use fatal in ospfd: control socket setup failed typhoon 1 ..sbin/ospfd$ I borrowed the fd passing code from slaacd. > > > > > Could there be a case where this causes ospfd to hang on start in the > > connect? Not sure if we can sleep doing a connect() to a AF_UNIX socket. I never observed a hangin ospfctl which also does a connect on the control socket. But I could not find the definitiv answer. Remi Index: control.c === RCS file: /cvs/src/usr.sbin/ospfd/control.c,v retrieving revision 1.44 diff -u -p -r1.44 control.c --- control.c 24 Jan 2017 04:24:25 - 1.44 +++ control.c 27 Aug 2018 21:17:42 - @@ -42,19 +42,29 @@ int control_init(char *path) { struct sockaddr_un sun; - int fd; + int fd, fd_check; mode_t old_umask; + bzero(&sun, sizeof(sun)); + sun.sun_family = AF_UNIX; + strlcpy(sun.sun_path, path, sizeof(sun.sun_path)); + + if ((fd_check = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) { + log_warn("control_init: socket check"); + return (-1); + } + if (connect(fd_check, (struct sockaddr *)&sun, sizeof(sun)) == 0) {
Re: ENA support
Mike Belopuhov writes: > On Sat, 25 Aug 2018 at 20:03, Zbyszek Żółkiewski > wrote: >> >> Hi, >> >> just a question: anyone tried/consider porting ENA (Elastic Network > Adapter) support to OpenBSD ( > https://github.com/amzn/amzn-drivers/tree/master/kernel/fbsd/ena), how hard > would be to get it to obsd? >> >> _ >> Zbyszek Żółkiewski > > Hi, > > It would be nice to have a thoughtful port or a partial rewrite of > this vendor code dump. IIRC, dlg@ was toying with the idea. > > Cheers, > Mike BTW, a merged and trimmed down version available directly from the FreeBSD tree: https://svnweb.freebsd.org/base/head/sys/dev/ena/
Re: ENA support
> Wiadomość napisana przez Mike Belopuhov w dniu > 27.08.2018, o godz. 22:06: > > It would be nice to have a thoughtful port or a partial rewrite of > this vendor code dump. IIRC, dlg@ was toying with the idea. I just realized that (i think) it would require not only driver port but whole nitro support, that make it non-trivial... _ Zbyszek Żółkiewski
Re: ENA support
On Sat, 25 Aug 2018 at 20:03, Zbyszek Żółkiewski wrote: > > Hi, > > just a question: anyone tried/consider porting ENA (Elastic Network Adapter) support to OpenBSD ( https://github.com/amzn/amzn-drivers/tree/master/kernel/fbsd/ena), how hard would be to get it to obsd? > > _ > Zbyszek Żółkiewski Hi, It would be nice to have a thoughtful port or a partial rewrite of this vendor code dump. IIRC, dlg@ was toying with the idea. Cheers, Mike
fix ssh build with DEBUG_PK enabled
Hi, While looking at a misplaced parenthesis I tried to compile ssh with DEBUG_PK enabled, but it's currently broken. Comments? OK? Index: auth2-hostbased.c === RCS file: /cvs/src/usr.bin/ssh/auth2-hostbased.c,v retrieving revision 1.36 diff -u -p -u -r1.36 auth2-hostbased.c --- auth2-hostbased.c 31 Jul 2018 03:10:27 - 1.36 +++ auth2-hostbased.c 27 Aug 2018 18:42:27 - @@ -78,7 +78,7 @@ userauth_hostbased(struct ssh *ssh) cuser, chost, pkalg, slen); #ifdef DEBUG_PK debug("signature:"); - sshbuf_dump_data(sig, siglen, stderr); + sshbuf_dump_data(sig, slen, stderr); #endif pktype = sshkey_type_from_name(pkalg); if (pktype == KEY_UNSPEC) {
Re: bgpd, streamline aspath matching
On Mon, Aug 27, 2018 at 12:11:43PM +0200, Claudio Jeker wrote: > This is in preparation for introducing as-sets (a fast lookup table for > when you want to make sure that your peering partner is realy only passing > you traffic he should). > > To make as-set possible lets do some cleanup beforehands. This mainly > removes one element from the filter_as struct, uses as_min for unary > operations and changes the way we pass the and check the neighbor-as. > as_compare() and aspath_match() now take the neighbor-as as last argument > and will match against it if AS_FLAG_NEIGHBORAS is set. Simplifies the > rde_filter_match() a fair bit. > And here is the bgpctl diff needed for this change. -- :wq Claudio Index: bgpctl.c === RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v retrieving revision 1.210 diff -u -p -r1.210 bgpctl.c --- bgpctl.c29 Jul 2018 13:02:01 - 1.210 +++ bgpctl.c27 Aug 2018 12:02:44 - @@ -159,7 +159,7 @@ main(int argc, char *argv[]) case IRRFILTER: if (!(res->flags & (F_IPV4|F_IPV6))) res->flags |= (F_IPV4|F_IPV6); - irr_main(res->as.as, res->flags, res->irr_outdir); + irr_main(res->as.as_min, res->flags, res->irr_outdir); break; case SHOW_MRT: if (pledge("stdio", NULL) == -1) @@ -2056,7 +2056,7 @@ show_mrt_dump(struct mrt_rib *mr, struct /* filter by AS */ if (req->as.type != AS_NONE && !aspath_match(mre->aspath, mre->aspath_len, - &req->as, req->as.as)) + &req->as, 0)) continue; if (req->flags & F_CTL_DETAIL) { @@ -2122,7 +2122,7 @@ network_mrt_dump(struct mrt_rib *mr, str /* filter by AS */ if (req->as.type != AS_NONE && !aspath_match(mre->aspath, mre->aspath_len, - &req->as, req->as.as)) + &req->as, 0)) continue; bzero(&net, sizeof(net)); Index: parser.c === RCS file: /cvs/src/usr.sbin/bgpctl/parser.c,v retrieving revision 1.82 diff -u -p -r1.82 parser.c --- parser.c10 Jul 2018 13:03:06 - 1.82 +++ parser.c27 Aug 2018 12:01:46 - @@ -614,7 +614,7 @@ match_token(int *argc, char **argv[], co } break; case ASNUM: - if (parse_asnum(word, wordlen, &res.as.as)) { + if (parse_asnum(word, wordlen, &res.as.as_min)) { match++; t = &table[i]; }
bgpd, streamline aspath matching
This is in preparation for introducing as-sets (a fast lookup table for when you want to make sure that your peering partner is realy only passing you traffic he should). To make as-set possible lets do some cleanup beforehands. This mainly removes one element from the filter_as struct, uses as_min for unary operations and changes the way we pass the and check the neighbor-as. as_compare() and aspath_match() now take the neighbor-as as last argument and will match against it if AS_FLAG_NEIGHBORAS is set. Simplifies the rde_filter_match() a fair bit. OK? -- :wq Claudio ? obj Index: bgpd.h === RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v retrieving revision 1.330 diff -u -p -r1.330 bgpd.h --- bgpd.h 9 Aug 2018 21:12:33 - 1.330 +++ bgpd.h 27 Aug 2018 10:03:55 - @@ -647,7 +647,6 @@ enum aslen_spec { }; struct filter_as { - u_int32_t as; u_int16_t flags; enum as_spectype; u_int8_top; Index: parse.y === RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v retrieving revision 1.330 diff -u -p -r1.330 parse.y --- parse.y 27 Aug 2018 09:49:00 - 1.330 +++ parse.y 27 Aug 2018 10:03:56 - @@ -1902,7 +1902,7 @@ filter_as : as4number_any { if (($$ = calloc(1, sizeof(struct filter_as_l))) == NULL) fatal(NULL); - $$->a.as = $1; + $$->a.as_min = $1; $$->a.op = OP_EQ; } | NEIGHBORAS{ @@ -1916,7 +1916,7 @@ filter_as : as4number_any { NULL) fatal(NULL); $$->a.op = $1; - $$->a.as = $2; + $$->a.as_min = $2; } | as4number_any binaryop as4number_any { if (($$ = calloc(1, sizeof(struct filter_as_l))) == Index: printconf.c === RCS file: /cvs/src/usr.sbin/bgpd/printconf.c,v retrieving revision 1.109 diff -u -p -r1.109 printconf.c --- printconf.c 11 Jul 2018 14:08:46 - 1.109 +++ printconf.c 27 Aug 2018 10:03:56 - @@ -619,10 +619,10 @@ void print_as(struct filter_rule *r) printf("%s ", log_as(r->match.as.as_max)); break; case OP_NE: - printf("!= %s ", log_as(r->match.as.as)); + printf("!= %s ", log_as(r->match.as.as_min)); break; default: - printf("%s ", log_as(r->match.as.as)); + printf("%s ", log_as(r->match.as.as_min)); break; } } Index: rde.c === RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v retrieving revision 1.414 diff -u -p -r1.414 rde.c --- rde.c 9 Aug 2018 12:54:06 - 1.414 +++ rde.c 27 Aug 2018 10:03:57 - @@ -2149,7 +2149,7 @@ rde_dump_filter(struct prefix *p, struct return; if (req->type == IMSG_CTL_SHOW_RIB_AS && !aspath_match(asp->aspath->data, asp->aspath->len, - &req->as, req->as.as)) + &req->as, 0)) return; if (req->type == IMSG_CTL_SHOW_RIB_COMMUNITY && !community_match(asp, req->community.as, @@ -3769,5 +3769,4 @@ rde_mark_prefixsets_dirty(struct prefixs } } } - return; } Index: rde_filter.c === RCS file: /cvs/src/usr.sbin/bgpd/rde_filter.c,v retrieving revision 1.99 diff -u -p -r1.99 rde_filter.c --- rde_filter.c3 Aug 2018 16:31:22 - 1.99 +++ rde_filter.c27 Aug 2018 10:03:57 - @@ -340,7 +340,6 @@ int rde_filter_match(struct filter_rule *f, struct rde_peer *peer, struct filterstate *state, struct prefix *p) { - u_int32_t pas; int cas, type; int64_t las, ld1, ld2; struct prefixset_item *psi; @@ -349,20 +348,16 @@ rde_filter_match(struct filter_rule *f, if (state != NULL) asp = &state->aspath; - if (asp != NULL && f->match.as.type != AS_NONE) { - if (f->match.as.flags & AS_FLAG_NEIGHBORAS) - pas = peer->conf.remote_as; - else - pas = f->match.as.as; - if (aspath_match(asp->aspath->data, asp->aspath->len, - &f->match.as, pas) == 0) - return (0); - } - if (f->peer.ebgp && !peer->conf.ebgp) return (0); if (f->peer.ibgp && peer->conf.ebgp) retur
add set time-of-day clock code for OPL based sparc64 machines
i have an m4000 that would come up saying that it was 2023, which is hard for ntpd to deal with. the rtc in these machines is based on a value the firmware manages, but we never tell the firmware what we think the time is. this diff moves all the opl firwmare handling into the prtc driver, and adds the todr_settime side of things so the time is kept across reboots. there's a bunch of dicking around with %sys_tick we could do, but i can't see what the advantage would be. ok? Index: dev/prtc.c === RCS file: /cvs/src/sys/arch/sparc64/dev/prtc.c,v retrieving revision 1.3 diff -u -p -r1.3 prtc.c --- dev/prtc.c 10 May 2014 12:36:22 - 1.3 +++ dev/prtc.c 27 Aug 2018 07:26:44 - @@ -49,6 +49,9 @@ struct cfdriver prtc_cd = { intprtc_gettime(todr_chip_handle_t, struct timeval *); intprtc_settime(todr_chip_handle_t, struct timeval *); +intprtc_opl_gettime(todr_chip_handle_t, struct timeval *); +intprtc_opl_settime(todr_chip_handle_t, struct timeval *); + int prtc_match(struct device *parent, void *match, void *aux) { @@ -64,6 +67,14 @@ void prtc_attach(struct device *parent, struct device *self, void *aux) { todr_chip_handle_t handle; + char buf[32]; + int opl; + + opl = OF_getprop(findroot(), "name", buf, sizeof(buf)) > 0 && + strcmp(buf, "SUNW,SPARC-Enterprise") == 0; + + if (opl) + printf(": OPL"); printf("\n"); @@ -72,26 +83,25 @@ prtc_attach(struct device *parent, struc panic("couldn't allocate todr_handle"); handle->cookie = self; - handle->todr_gettime = prtc_gettime; - handle->todr_settime = prtc_settime; + if (opl) { + handle->todr_gettime = prtc_opl_gettime; + handle->todr_settime = prtc_opl_settime; + } else { + handle->todr_gettime = prtc_gettime; + handle->todr_settime = prtc_settime; + } handle->bus_cookie = NULL; handle->todr_setwen = NULL; + todr_handle = handle; } int prtc_gettime(todr_chip_handle_t handle, struct timeval *tv) { - u_int32_t tod = 0; char buf[32]; - - if (OF_getprop(findroot(), "name", buf, sizeof(buf)) > 0 && - strcmp(buf, "SUNW,SPARC-Enterprise") == 0) { - tv->tv_sec = prom_opl_get_tod(); - tv->tv_usec = 0; - return (0); - } + u_int32_t tod = 0; snprintf(buf, sizeof(buf), "h# %08lx unix-gettod", (long)&tod); OF_interpret(buf, 0); @@ -105,4 +115,56 @@ int prtc_settime(todr_chip_handle_t handle, struct timeval *tv) { return (0); -} +} + +int +prtc_opl_gettime(todr_chip_handle_t handle, struct timeval *tv) +{ + struct { + cell_t name; + cell_t nargs; + cell_t nrets; + cell_t stick; + cell_t time; + } args = { + .name = ADR2CELL("FJSV,get-tod"), + .nargs = 0, + .nrets = 2, + }; + + if (openfirmware(&args) == -1) + return (-1); + + tv->tv_sec = args.time; + tv->tv_usec = 0; + + return (0); +} + +int +prtc_opl_settime(todr_chip_handle_t handle, struct timeval *tv) +{ + struct timeval otv; + struct { + cell_t name; + cell_t nargs; + cell_t nrets; + cell_t diff; + } args = { + .name = ADR2CELL("FJSV,set-domain-time"), + .nargs = 1, + .nrets = 0, + }; + + if (prtc_opl_gettime(handle, &otv) == -1) + return (-1); + + args.diff = tv->tv_sec - otv.tv_sec; + if (args.diff == 0) + return (-1); + + if (openfirmware(&args) == -1) + return (-1); + + return (0); +} Index: sparc64/ofw_machdep.c === RCS file: /cvs/src/sys/arch/sparc64/sparc64/ofw_machdep.c,v retrieving revision 1.33 diff -u -p -r1.33 ofw_machdep.c --- sparc64/ofw_machdep.c 7 Mar 2016 13:21:51 - 1.33 +++ sparc64/ofw_machdep.c 27 Aug 2018 07:26:44 - @@ -748,27 +748,6 @@ prom_serengeti_set_console_input(const c return (const char *)args.old; } -time_t -prom_opl_get_tod(void) -{ - static struct { - cell_t name; - cell_t nargs; - cell_t nreturns; - cell_t stick; - cell_t time; - } args; - - args.name = ADR2CELL("FJSV,get-tod"); - args.nargs = 0; - args.nreturns = 2; - - if (openfirmware(&args) == -1) - return (time_t)-1; - - return (time_t)args.time; -} - uint64_t prom_set_sun4v_api_version(uint64_t api_group, uint64_t major, uint64_t minor, uint64_t *supported_minor)
Re: libtool: handle fork() error
On Sun, Aug 26, 2018 at 04:13:11PM +0200, Christian Weisgerber wrote: > I noticed this curious error in a package bulk build: > Use of uninitialized value $pid in numeric eq (==) at > /usr/libdata/perl5/LT/Exec.pm line 96. > > Perl's fork() wrapper returns undef rather than -1 on error. > Handle this correctly. OK? > > Index: LT/Exec.pm > === > RCS file: /cvs/src/usr.bin/libtool/LT/Exec.pm,v > retrieving revision 1.4 > diff -u -p -r1.4 Exec.pm > --- LT/Exec.pm11 Jul 2012 12:54:07 - 1.4 > +++ LT/Exec.pm26 Aug 2018 14:00:15 - > @@ -93,7 +93,7 @@ sub command_run > } > tsay { "@l" }; > my $pid = fork(); > - if ($pid == -1) { > + if (!defined $pid) { > die "Couldn't fork while running @l\n"; > } > if ($pid == 0) { > -- > Christian "naddy" Weisgerber na...@mips.inka.de Okay, I actually had this in one of my trees, but forgot to commit it. :)