sync acme-client.conf.5 with the example about LE API url
The example uses acme-v02.api.letsencrypt.org while acme-client.conf(5)
still uses v01.
Index: acme-client.conf.5
===
RCS file: /data/cvs/src/usr.sbin/acme-client/acme-client.conf.5,v
retrieving revision 1.20
diff -u -p -r1.20 acme-client.conf.5
--- acme-client.conf.5 17 Jun 2019 12:42:52 - 1.20
+++ acme-client.conf.5 4 Jul 2019 04:51:15 -
@@ -63,7 +63,7 @@ Macros are not expanded inside quotes.
.Pp
For example:
.Bd -literal -offset indent
-api_url="https://acme-v01.api.letsencrypt.org/directory;
+api_url="https://acme-v02.api.letsencrypt.org/directory;
authority letsencrypt {
api url $api_url
account key "/etc/acme/letsencrypt-privkey.pem"
aggr(4): a new LACP driver
aggr(4) came about after i had several goes at making the transmit path in trunk(4) mpsafe. we need this at work to try and wring a bit more speed out of our firewalls. every attempt at this had me get overwhelmed with the twistiness that comes with it supporting several different modes of operation, and the diffs got too large with too many different changes all together. we've also been hit with some weirdness in the trunk(4) lacp code where it brought a port up when its link was unidirectional, and mistakenly sent traffic to a switch which didn't think it should be collecting traffic from us. this effectively blackholed half the traffic. so i had a go at writing a small replacement driver. this didn't really go as planned. it took me about half a day and a few hundred lines of code to implement a small driver with mpsafe tx and rx. at that point it was basically the trunk(4) loadbalance mode driver. then i started on the lacp protocol by following 802.1AX-2014, which is where the plan fell apart. it took an order of magnitude more time, and the driver is now over 2k lines of code. however, it does implement the lacp state machines properly and appears to be behave correctly where trunk(4) did not before. there are still some things to do, but at this stage there's some consensus that it should continue in the tree. in the interests of full disclosure, here are a list of the different features between aggr(4) and trunk(4): - trunk(4) unconditionally makes trunkports promisc - aggr(4) only makes ports promisc when aggr is made promisc - the unconditional promisc is what allows trunk(4) to receive lacp packets - aggr(4) adds the right ethernet slow protocols multicast group (01:80:c2:00:00:0e) as a multicast address to trunkport interfaces, which is how they rx lacp packets. - trunk(4) uses the lladdr of the "primary" or first port added for its own lladdr. it selects a new primary and tries to reconfigure with that lladdr when the current primary is removed - aggr(4) generates it's own lladdr. this happens to be random at the moment, but it can be configured by an administrator as expected. this is valid according to 802.1AX, and it simplifies the code because there's no "primary" interface and no potential address reconfiguration when member ports are removed. - aggr(4) effectively operates each trunkport independently with their own state machines. the only time they really coordinate is to select which upstream aggregation to use, and then check whether other ports can be added to it. - aggr(4) implements ifq bypass like vlan(4). this plus making the tx path mpsafe effectively makes transmit twice as fast as trunk(4). - aggr(4) reuses trunks ioctls so config is basically the same. you just don't set a trunkproto, but maybe you set lladdr. every operating system has a different name for these drivers. linux has "bond", and freebsd and dragonfly have "lagg". these seem to do the same thing as "trunk" by supporting different modes in the one driver. netbsd has "agr" and solaris has "aggr", both of which are lacp only drivers. i picked aggr because the solaris support seemed the most similar to what i wanted to do. i only looked up what Nx had a few minutes ago. "portchannel" seems too clumsy. while i have used this in production recently, there is work still to do on it. i just want to do it in the tree instead. this is what it looks like in production: aggr0: flags=8943 mtu 9000 lladdr fe:e1:ba:d0:22:85 index 10 priority 0 llprio 7 trunk: trunkproto lacp trunk id: [(8000,fe:e1:ba:d0:22:85,000A,,), (1000,00:23:04:ee:be:01,8019,,)] trunkport myx0 lacp_state actor activity,aggregation,sync,collecting,distributing trunkport myx0 lacp_state partner activity,aggregation,sync,collecting,distributing trunkport myx0 collecting,distributing trunkport myx1 lacp_state actor activity,aggregation,sync,collecting,distributing trunkport myx1 lacp_state partner activity,aggregation,sync,collecting,distributing trunkport myx1 collecting,distributing groups: aggr media: Ethernet autoselect status: active this sits under a ton of vlan interfaces, which in turn sit under carp. that's why the aggr ends up promisc. ok? Index: net/if_aggr.c === RCS file: net/if_aggr.c diff -N net/if_aggr.c --- /dev/null 1 Jan 1970 00:00:00 - +++ net/if_aggr.c 27 Jun 2019 03:14:16 - @@ -0,0 +1,2675 @@ +/* $OpenBSD */ + +/* + * Copyright (c) 2019 The University of Queensland + * + * 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
cwm: label application windows with command name
Applications are a nice way to stuff frequently used programs behind
mnemonic names, so starting them is one keybind and a few characters
away.
Labels are nice for finding windows quickly. All windows start with an
empty label.
Now, switching windows back and forth, I want to reach my application
windows most of the time, but I want to do so as quickly as spawning
them, without manually setting a label for each of them.
Diff below labels application windows with their command name, which
is the application name itself. So with the following configuration
command app "xterm -e sh -c 'something; long_to --type'"
after spawing that, `C-slash app ' navigates to it so one does
not have to search for the the window title or program name.
Does that sound useful to anyone?
Is there a better way to do it? This attempt simply stuffs the label
into screen context so it can be passed along from command to client
context.
Index: client.c
===
RCS file: /cvs/xenocara/app/cwm/client.c,v
retrieving revision 1.255
diff -u -p -r1.255 client.c
--- client.c7 Mar 2019 14:28:17 - 1.255
+++ client.c3 Jul 2019 20:15:51 -
@@ -67,7 +67,7 @@ client_init(Window win, struct screen_ct
cc = xmalloc(sizeof(*cc));
cc->sc = sc;
cc->win = win;
- cc->label = NULL;
+ cc->label = sc->label;
cc->gc = NULL;
cc->flags = 0;
cc->stackingorder = 0;
Index: kbfunc.c
===
RCS file: /cvs/xenocara/app/cwm/kbfunc.c,v
retrieving revision 1.165
diff -u -p -r1.165 kbfunc.c
--- kbfunc.c7 Mar 2019 14:28:17 - 1.165
+++ kbfunc.c3 Jul 2019 20:15:54 -
@@ -517,6 +517,7 @@ kbfunc_menu_cmd(void *ctx, struct cargs
search_match_cmd, search_print_cmd)) != NULL) {
cmd = (struct cmd_ctx *)mi->ctx;
u_spawn(cmd->path);
+ sc->label = xstrdup(cmd->name);
}
menuq_clear();
Index: screen.c
===
RCS file: /cvs/xenocara/app/cwm/screen.c,v
retrieving revision 1.93
diff -u -p -r1.93 screen.c
--- screen.c8 Mar 2019 20:33:30 - 1.93
+++ screen.c3 Jul 2019 20:15:55 -
@@ -54,6 +54,7 @@ screen_init(int which)
sc->visual = DefaultVisual(X_Dpy, sc->which);
sc->cycling = 0;
sc->hideall = 0;
+ sc->label = NULL;
conf_screen(sc);
startup file - error message
If you have something like this in your .mg file:
find-file /home/lum/test
imaginary-command
When you open mg you will see an error:
Error loading file /home/lum/test at line 2
If you open files in your .mg file, but then have any kind of error with
the evaluation of lines afterwards (even non file opening/closing errors),
mg uses the last filename opened in the error message. Hence, the error
should have said:
Error loading file /home/lum/.mg at line 2
..since 'imaginary-command' IS imaginary.
Comments/oks?
Mark
Index: extend.c
===
RCS file: /cvs/src/usr.bin/mg/extend.c,v
retrieving revision 1.65
diff -u -p -u -p -r1.65 extend.c
--- extend.c22 Jun 2019 15:38:15 - 1.65
+++ extend.c3 Jul 2019 21:25:00 -
@@ -657,7 +657,7 @@ load(const char *fname)
{
int s = TRUE, line, ret;
int nbytes = 0;
- char excbuf[128];
+ char excbuf[128], fncpy[NFILEN];
FILE*ffp;
if ((fname = adjustname(fname, TRUE)) == NULL)
@@ -670,7 +670,8 @@ load(const char *fname)
(void)ffclose(ffp, NULL);
return (FALSE);
}
-
+ /* keep a copy of fname incase of evaluation errors in excline. */
+ (void)strlcpy(fncpy, fname, sizeof(fncpy));
line = 0;
while ((s = ffgetline(ffp, excbuf, sizeof(excbuf) - 1, ))
== FIOSUC) {
@@ -679,7 +680,7 @@ load(const char *fname)
if (excline(excbuf) != TRUE) {
s = FIOERR;
dobeep();
- ewprintf("Error loading file %s at line %d", fname,
line);
+ ewprintf("Error loading file %s at line %d", fncpy,
line);
break;
}
}
socket splicing without kernel lock
Hi,
I would like to remove a useless kernel lock during socket splicing.
We have a socket "so" that splices data to socket "sosp". Everytime
when space in sosp gets available, we add a task to move data from
so to sosp. Additionally we call sowakeup() from sowwakeup(). I
have added this as it is possible to splice from so to sosp and
write from userland to sosp simultaneously. In practice this does
not make sense as the data streams from two sources would get mixed.
Nothing uses this. So it is not neccessay to inform userland that
it is possible to write.
Note that sowakeup() takes the kernel lock. So when I do not call
it for a spliced socket, there is no kernel lock in the TCP splicing
path anymore.
But then I have to wakeup userland for the wirting socket in
sounsplice().
ok?
bluhm
Index: sys/kern/uipc_socket.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.231
diff -u -p -r1.231 uipc_socket.c
--- sys/kern/uipc_socket.c 17 Dec 2018 16:46:59 - 1.231
+++ sys/kern/uipc_socket.c 3 Jul 2019 13:56:09 -
@@ -220,9 +220,10 @@ sofree(struct socket *so, int s)
if (so->so_sp) {
if (issplicedback(so))
sounsplice(so->so_sp->ssp_soback, so,
- so->so_sp->ssp_soback != so);
+ so->so_sp->ssp_soback == so ? 3 : 2);
if (isspliced(so))
- sounsplice(so, so->so_sp->ssp_socket, 0);
+ sounsplice(so, so->so_sp->ssp_socket,
+ so == so->so_sp->ssp_socket ? 3 : 1);
}
#endif /* SOCKET_SPLICE */
sbrelease(so, >so_snd);
@@ -1148,7 +1149,7 @@ sosplice(struct socket *so, int fd, off_
return (error);
}
if (so->so_sp->ssp_socket)
- sounsplice(so, so->so_sp->ssp_socket, 1);
+ sounsplice(so, so->so_sp->ssp_socket, 0);
sbunlock(so, >so_rcv);
return (0);
}
@@ -1227,7 +1228,7 @@ sosplice(struct socket *so, int fd, off_
}
void
-sounsplice(struct socket *so, struct socket *sosp, int wakeup)
+sounsplice(struct socket *so, struct socket *sosp, int freeing)
{
soassertlocked(so);
@@ -1236,8 +1237,11 @@ sounsplice(struct socket *so, struct soc
sosp->so_snd.sb_flags &= ~SB_SPLICE;
so->so_rcv.sb_flags &= ~SB_SPLICE;
so->so_sp->ssp_socket = sosp->so_sp->ssp_soback = NULL;
- if (wakeup && soreadable(so))
+ /* Do not wakeup a socket that is about to be freed. */
+ if ((freeing & 1) == 0 && soreadable(so))
sorwakeup(so);
+ if ((freeing & 2) == 0 && sowriteable(sosp))
+ sowwakeup(sosp);
}
void
@@ -1249,7 +1253,7 @@ soidle(void *arg)
s = solock(so);
if (so->so_rcv.sb_flags & SB_SPLICE) {
so->so_error = ETIMEDOUT;
- sounsplice(so, so->so_sp->ssp_socket, 1);
+ sounsplice(so, so->so_sp->ssp_socket, 0);
}
sounlock(so, s);
}
@@ -1574,7 +1578,7 @@ somove(struct socket *so, int wait)
so->so_error = error;
if (((so->so_state & SS_CANTRCVMORE) && so->so_rcv.sb_cc == 0) ||
(sosp->so_state & SS_CANTSENDMORE) || maxreached || error) {
- sounsplice(so, sosp, 1);
+ sounsplice(so, sosp, 0);
return (0);
}
if (timerisset(>so_idletv))
@@ -1620,6 +1624,8 @@ sowwakeup(struct socket *so)
#ifdef SOCKET_SPLICE
if (so->so_snd.sb_flags & SB_SPLICE)
task_add(sosplice_taskq, >so_sp->ssp_soback->so_splicetask);
+ if (issplicedback(so))
+ return;
#endif
sowakeup(so, >so_snd);
}
Index: share/man/man9/sosplice.9
===
RCS file: /data/mirror/openbsd/cvs/src/share/man/man9/sosplice.9,v
retrieving revision 1.9
diff -u -p -r1.9 sosplice.9
--- share/man/man9/sosplice.9 15 Aug 2018 12:10:49 - 1.9
+++ share/man/man9/sosplice.9 3 Jul 2019 21:42:34 -
@@ -206,10 +206,13 @@ will call
to trigger the transfer when new data or buffer space is available.
While socket splicing is active, any
.Xr read 2
-from the source socket will block and the wakeup will not be delivered
-to the file descriptor.
-A read event or a socket error is signaled to userland after
-dissolving.
+from the source socket will block.
+Neither read nor write wakeups will be delivered to the file
+descriptors.
+After dissolving, a read event or a socket error is signaled to
+userland on the source socket.
+If space is available, a write event will be signaled on the drain
+socket.
.Sh RETURN VALUES
.Fn sosplice
returns 0 on success and otherwise the error number.
pushing option to dhclient from netstart
Dear reader,
/etc/netstart pushed option from 'dhcp #options#' beside ifconfig and before up.
It's easy to have this behavior like this
#options#
dhcp
OTA dhclient could be feed with argument like -l or -L , but those are
not easily configured.
it seams like a minor typo was introduce, or there is another/better
way that eluded me.
current# diff -bu /etc/netstart.base /etc/netstart
--- /etc/netstart.base Wed Jul 3 22:23:35 2019
+++ /etc/netstart Wed Jul 3 22:24:22 2019
@@ -65,7 +65,7 @@
_cmds[$_prev]="${_c[@]}"
;;
dhcp) _c[0]=
- _cmds[${#_cmds[*]}]="ifconfig $_if ${_c[@]} up;dhclient $_if"
+ _cmds[${#_cmds[*]}]="ifconfig $_if up;dhclient $_if ${_c[@]}"
V4_DHCPCONF=true
;;
'!'*) _cmd=$(print -- "${_c[@]}" | sed 's/\$if/'$_if'/g')
current# cat /etc/hostname.vether0
dhcp -l /tmp/lol
current# sh /etc/netstart -n vether0
ifconfig vether0 up;dhclient vether0 -l /tmp/lol
Can we fix this ?
Moreover is it still require to up the interface before ?
( the diff above contains space, tr them or -b )
Thank you for reading all that.
Best.
--
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do
Re: Softraid bootloader size allowance
On Wed, Jul 03, 2019 at 08:17:09PM +0200, Otto Moerbeek wrote: > > Well, the question I had is: can I just make that whole block bigger. > > Thus making the partition lead-in bigger. Is there a reason that whole > > area can't just be enlarged? > > > > I'm rebuilding on a single-disk system an OpenBSD 6.5 with > > SR_BOOT_LOADER_SIZE > > set to 1024. Then I'll see how that behaves when I try to build a raid1 > > and install onto it. > > I think that would break existing softraid setups. You cannot do such > things without being backward compatible. Yeah. I suppose I should've realized that issue when I first asked the question. Clear now. So, the bigger "how can we fix this so that a debugging ofwboot could be installed on sparc64" is a larger and more complicated question. In the short term, I'm going to produce an odd-ball system on my own where I can load the debugging ofwboot to try to diagnose my own issue. But, I think we should think about the larger issue of there being an obvious need for bootloaders, at least in some architectures, being larger than 160kb. Any idea how we could allow for that in softraid, while not mucking up existing installations? - Chris
Re: Softraid bootloader size allowance
On Wed, Jul 03, 2019 at 02:05:24PM -0400, Chris Ross wrote: > On Wed, Jul 03, 2019 at 04:20:59PM +0200, Christian Weisgerber wrote: > > Chris Ross: > > > > > Is there a hard reason SR_BOOT_LOADER_SIZE cannot be raised to sometime > > > larger, perhaps 1024 (instead of the current 320) ? > > > > That size is part of the disk layout. > > > > Looking at , the layout of a softraid partition > > is this: > > > > 16 sectors, unused (potential disklabel, boot block) > > + 64 sectors softraid metadata > > + 320 sectors boot loader space > > + 128 sectors boot block space > > followed by the actual data > > > > The boot block space is of dubious usefulness and unused as far as > > I can tell, so I guess it could be reused to modestly extend the > > boot loader space if there ever were a pressing reason. > > Well, the question I had is: can I just make that whole block bigger. > Thus making the partition lead-in bigger. Is there a reason that whole > area can't just be enlarged? > > I'm rebuilding on a single-disk system an OpenBSD 6.5 with SR_BOOT_LOADER_SIZE > set to 1024. Then I'll see how that behaves when I try to build a raid1 > and install onto it. > > For the case I had, I was teying to load a ~250mb boot loader, so 448 > sectors wouldn't be enough for me. > >- Chris > I think that would break existing softraid setups. You cannot do such things without being backward compatible. -Otto
Re: Softraid bootloader size allowance
On Wed, Jul 03, 2019 at 04:20:59PM +0200, Christian Weisgerber wrote: > Chris Ross: > > > Is there a hard reason SR_BOOT_LOADER_SIZE cannot be raised to sometime > > larger, perhaps 1024 (instead of the current 320) ? > > That size is part of the disk layout. > > Looking at , the layout of a softraid partition > is this: > > 16 sectors, unused (potential disklabel, boot block) > + 64 sectors softraid metadata > + 320 sectors boot loader space > + 128 sectors boot block space > followed by the actual data > > The boot block space is of dubious usefulness and unused as far as > I can tell, so I guess it could be reused to modestly extend the > boot loader space if there ever were a pressing reason. Well, the question I had is: can I just make that whole block bigger. Thus making the partition lead-in bigger. Is there a reason that whole area can't just be enlarged? I'm rebuilding on a single-disk system an OpenBSD 6.5 with SR_BOOT_LOADER_SIZE set to 1024. Then I'll see how that behaves when I try to build a raid1 and install onto it. For the case I had, I was teying to load a ~250mb boot loader, so 448 sectors wouldn't be enough for me. - Chris
Re: Softraid bootloader size allowance
Chris Ross: > Is there a hard reason SR_BOOT_LOADER_SIZE cannot be raised to sometime > larger, perhaps 1024 (instead of the current 320) ? That size is part of the disk layout. Looking at , the layout of a softraid partition is this: 16 sectors, unused (potential disklabel, boot block) + 64 sectors softraid metadata + 320 sectors boot loader space + 128 sectors boot block space followed by the actual data The boot block space is of dubious usefulness and unused as far as I can tell, so I guess it could be reused to modestly extend the boot loader space if there ever were a pressing reason. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: ospfd: point-to-point on ethernet interfaces
Works for me no problem. tested to IOS.
On 03.07.19 00:00, Remi Locherer wrote:
ping
On Mon, Jun 24, 2019 at 12:33:16AM +0200, Remi Locherer wrote:
Diff below adds to ospfd point to point support for Ethernet interfaces.
I successfully tested this against Junos and FastIron.
I first made the key word in the config "point-to-point". But then I
changed to "type p2p". The later would allow for "type nbma" or "type p2mp"
should we implement these types.
On Junos it looks like this:
area 0.0.0.0 {
interface ge-0/0/1.0 {
interface-type p2p;
}
}
On FastIron it's similar to IOS:
interface ethernet 1/2/1
ip address 10.10.10.5 255.255.255.0
ip ospf area 0
ip ospf network point-to-point
Comments, test reports and OKs are welcome.
Remi
Index: interface.c
===
RCS file: /cvs/src/usr.sbin/ospfd/interface.c,v
retrieving revision 1.82
diff -u -p -r1.82 interface.c
--- interface.c 11 Mar 2018 13:16:49 - 1.82
+++ interface.c 23 Jun 2019 11:27:57 -
@@ -190,6 +190,8 @@ if_new(struct kif *kif, struct kif_addr
if (kif->flags & IFF_BROADCAST &&
kif->flags & IFF_MULTICAST)
iface->type = IF_TYPE_BROADCAST;
+ if (iface->p2p)
+ iface->type = IF_TYPE_POINTOPOINT;
if (kif->flags & IFF_LOOPBACK) {
iface->type = IF_TYPE_POINTOPOINT;
iface->passive = 1;
@@ -351,6 +353,9 @@ if_act_start(struct iface *iface)
orig_rtr_lsa(iface->area);
return (0);
}
+
+ if (iface->p2p)
+ iface->type = IF_TYPE_POINTOPOINT;
switch (iface->type) {
case IF_TYPE_POINTOPOINT:
Index: ospfd.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
retrieving revision 1.108
diff -u -p -r1.108 ospfd.c
--- ospfd.c 16 May 2019 05:49:22 - 1.108
+++ ospfd.c 23 Jun 2019 21:06:44 -
@@ -911,6 +911,22 @@ merge_interfaces(struct area *a, struct
if_fsm(i, IF_EVT_UP);
}
+ if (i->p2p != xi->p2p) {
+ /* re-add interface to enable or disable DR election */
+ if (ospfd_process == PROC_OSPF_ENGINE)
+ if_fsm(i, IF_EVT_DOWN);
+ else if (ospfd_process == PROC_RDE_ENGINE)
+ rde_nbr_iface_del(i);
+ LIST_REMOVE(i, entry);
+ if_del(i);
+ LIST_REMOVE(xi, entry);
+ LIST_INSERT_HEAD(>iface_list, xi, entry);
+ xi->area = a;
+ if (ospfd_process == PROC_OSPF_ENGINE)
+ xi->state = IF_STA_NEW;
+ continue;
+ }
+
strlcpy(i->dependon, xi->dependon,
sizeof(i->dependon));
i->depend_ok = xi->depend_ok;
Index: ospfd.conf.5
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfd.conf.5,v
retrieving revision 1.57
diff -u -p -r1.57 ospfd.conf.5
--- ospfd.conf.510 Jun 2019 06:07:15 - 1.57
+++ ospfd.conf.523 Jun 2019 22:10:32 -
@@ -419,6 +419,9 @@ Router.
.It Ic transmit-delay Ar seconds
Set the transmit delay.
The default value is 1; valid range is 1\-3600 seconds.
+.It Ic type p2p
+Set the interface type to point to point.
+This disables the election of a DR and BDR for the given interface.
.El
.Sh FILES
.Bl -tag -width "/etc/ospfd.conf" -compact
Index: ospfd.h
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfd.h,v
retrieving revision 1.104
diff -u -p -r1.104 ospfd.h
--- ospfd.h 16 May 2019 05:49:22 - 1.104
+++ ospfd.h 23 Jun 2019 11:28:24 -
@@ -363,6 +363,7 @@ struct iface {
u_int8_t linkstate;
u_int8_t priority;
u_int8_t passive;
+ u_int8_t p2p;
};
struct ifaddrchange {
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/ospfd/parse.y,v
retrieving revision 1.98
diff -u -p -r1.98 parse.y
--- parse.y 7 Jun 2019 04:57:45 - 1.98
+++ parse.y 23 Jun 2019 22:04:22 -
@@ -129,7 +129,7 @@ typedef struct {
%tokenAREA INTERFACE ROUTERID FIBPRIORITY FIBUPDATE REDISTRIBUTE
RTLABEL
%tokenRDOMAIN RFC1583COMPAT STUB ROUTER SPFDELAY SPFHOLDTIME EXTTAG
%tokenAUTHKEY AUTHTYPE AUTHMD AUTHMDKEYID
-%token METRIC PASSIVE
+%token METRIC P2P PASSIVE
%tokenHELLOINTERVAL FASTHELLOINTERVAL TRANSMITDELAY
%tokenRETRANSMITINTERVAL ROUTERDEADTIME ROUTERPRIORITY
%tokenSET TYPE
@@ -743,6 +743,7 @@ interfaceopts_l : interfaceopts_l interf
missing splnet in network drivers
The recent mii_tick diff made me ponder whether the mii tick timeout
could be put in the mii_data struct rather than each driver softc (not
that a good idea, actually).
While looking at this, I noticed that two drivers may end up invoking
mii_tick() while not being at IPL_NET.
bnx: bnx_tick() can get invoked either from the interrupt handler, or
from a timeout.
sk: on some boards, sk_tick() gets invoked from timeout, but may end up
invoking sk_intr_bcom() which is intended to run at IPL_NET.
This diff has only been compile-tested, for lack of such hardware.
Index: if_bnx.c
===
RCS file: /OpenBSD/src/sys/dev/pci/if_bnx.c,v
retrieving revision 1.125
diff -u -p -r1.125 if_bnx.c
--- if_bnx.c10 Mar 2018 10:51:46 - 1.125
+++ if_bnx.c3 Jul 2019 06:40:47 -
@@ -5457,6 +5457,9 @@ bnx_tick(void *xsc)
struct ifnet*ifp = >arpcom.ac_if;
struct mii_data *mii = NULL;
u_int32_t msg;
+ int s;
+
+ s = splnet();
/* Tell the firmware that the driver is still running. */
#ifdef BNX_DEBUG
@@ -5489,7 +5492,7 @@ bnx_tick(void *xsc)
}
bnx_tick_exit:
- return;
+ splx(s);
}
//
Index: if_sk.c
===
RCS file: /OpenBSD/src/sys/dev/pci/if_sk.c,v
retrieving revision 1.189
diff -u -p -r1.189 if_sk.c
--- if_sk.c 4 Jun 2017 04:29:23 - 1.189
+++ if_sk.c 3 Jul 2019 06:40:47 -
@@ -1703,15 +1703,20 @@ sk_tick(void *xsc_if)
struct sk_if_softc *sc_if = xsc_if;
struct mii_data *mii = _if->sk_mii;
struct ifnet *ifp = _if->arpcom.ac_if;
- int i;
+ int i, s;
DPRINTFN(2, ("sk_tick\n"));
- if (!(ifp->if_flags & IFF_UP))
+ s = splnet();
+
+ if (!(ifp->if_flags & IFF_UP)) {
+ splx(s);
return;
+ }
if (sc_if->sk_phytype == SK_PHYTYPE_BCOM) {
sk_intr_bcom(sc_if);
+ splx(s);
return;
}
@@ -1729,6 +1734,7 @@ sk_tick(void *xsc_if)
if (i != 3) {
timeout_add_sec(_if->sk_tick_ch, 1);
+ splx(s);
return;
}
@@ -1736,6 +1742,7 @@ sk_tick(void *xsc_if)
SK_XM_CLRBIT_2(sc_if, XM_IMR, XM_IMR_GP0_SET);
SK_XM_READ_2(sc_if, XM_ISR);
mii_tick(mii);
+ splx(s);
timeout_del(_if->sk_tick_ch);
}
