vmd(8): add MTU feature support to vionet device
The following diff adds in virtio 1.1's VIRTIO_NET_F_MTU feature support
to vmd(8)'s virtio networking device. This allows for communicating an MTU
to the guest driver and then enforcing it in the emulated device.
When the feature is offered, per Virtio v1.1, 5.1.4.1 [1]:
"The device MUST NOT pass received packets that exceed mtu (plus low
level ethernet header length) size with gso_type NONE or ECN after
VIRTIO_NET_F_MTU has been successfully negotiated."
(GSO is not supported or negotiated, so it's always NONE. This is
primarly because the vmd vionet device also doesn't support or negotiate
checksum offloading.)
The prior logic in place simply checked the packet was of a allowable
size, which meant the largest IP packet (65535) plus an ethernet header.
If testing the diff, you can change the VIONET_MTU definition to
something other than 1500 and check that a non-OpenBSD guest defaults to
using the value and forbids setting it higher. This is easy in an Alpine
or Debian Linux guest using:
a) to view the mtu: ip link
b) to set the mtu: sudo ip link set dev mtu
For example:
dave@debian:~$ sudo ip link set dev enp0s2 mtu 1501
Error: mtu greater than device maximum.
Since the diff lacks context of the goto, it jumps to section that
advances to the next ring
Currently, vio(4) does not negotiate this feature and won't obey it. I'm
working on that separately.
OK? Feedback?
[1]
https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-204
Index: virtio.c
===
RCS file: /cvs/src/usr.sbin/vmd/virtio.c,v
retrieving revision 1.87
diff -u -p -r1.87 virtio.c
--- virtio.c18 May 2021 11:06:43 - 1.87
+++ virtio.c24 May 2021 01:31:22 -
@@ -60,6 +60,7 @@ int nr_vioblk;
#define MAXPHYS(64 * 1024) /* max raw I/O transfer size */
+#define VIRTIO_NET_F_MTU (1<<3)
#define VIRTIO_NET_F_MAC (1<<5)
#define VMMCI_F_TIMESYNC (1<<0)
@@ -1046,6 +1047,26 @@ virtio_net_io(int dir, uint16_t reg, uin
*data = dev->mac[reg -
VIRTIO_CONFIG_DEVICE_CONFIG_NOMSI];
break;
+ case VIRTIO_CONFIG_DEVICE_CONFIG_NOMSI + 10:
+ if (sz == 2) {
+ *data = VIONET_MTU;
+ } else if (sz == 1) {
+ *data &= 0xFF00;
+ *data |= (uint32_t)(VIONET_MTU) & 0xFF;
+ } else {
+ log_warnx("%s: illegal read of vionet_mtu",
+ __progname);
+ }
+ break;
+ case VIRTIO_CONFIG_DEVICE_CONFIG_NOMSI + 11:
+ if (sz == 1) {
+ *data &= 0xFF00;
+ *data = (uint32_t)(VIONET_MTU >> 8) & 0xFF;
+ } else {
+ log_warnx("%s: illegal read of vionet_mtu",
+ __progname);
+ }
+ break;
case VIRTIO_CONFIG_DEVICE_FEATURES:
*data = dev->cfg.device_feature;
break;
@@ -1437,7 +1458,7 @@ vionet_notify_tx(struct vionet_dev *dev)
size_t pktsz, chunk_size = 0;
ssize_t dhcpsz;
int ret, num_enq, ofs, spc;
- char *vr, *pkt, *dhcppkt;
+ char *vr, *pkt = NULL, *dhcppkt;
struct vring_desc *desc, *pkt_desc, *hdr_desc;
struct vring_avail *avail;
struct vring_used *used;
@@ -1505,12 +1526,13 @@ vionet_notify_tx(struct vionet_dev *dev)
/* Remove virtio header descriptor len */
pktsz -= hdr_desc->len;
- /* Only allow buffer len < max IP packet + Ethernet header */
- if (pktsz > IP_MAXPACKET + ETHER_HDR_LEN) {
+ /* Drop frames larger than our MTU + ethernet header */
+ if (pktsz > VIONET_MTU + ETHER_HDR_LEN) {
log_warnx("%s: invalid packet size %lu", __func__,
pktsz);
- goto out;
+ goto drop_packet;
}
+
pkt = malloc(pktsz);
if (pkt == NULL) {
log_warn("malloc error alloc packet buf");
@@ -1590,6 +1612,7 @@ vionet_notify_tx(struct vionet_dev *dev)
goto out;
}
+ drop_packet:
ret = 1;
dev->cfg.isr_status = 1;
used->ring[used->idx & VIONET_QUEUE_MASK].id = hdr_desc_idx;
@@ -1965,6 +1988,9 @@ virtio_init(struct vmd_vm *vm, int child
vionet[i].pxeboot = 1;
vionet[i].idx = i;
vionet[i].pci_id = id;
+
+ /* Allow drivers to
vio.4: mention support provided by vmd(8)
Seems only right that vio.4 mention it's the driver used for the virtio networking device provided by vmd(8). OK? Index: vio.4 === RCS file: /cvs/src/share/man/man4/vio.4,v retrieving revision 1.15 diff -u -p -r1.15 vio.4 --- vio.4 24 Sep 2015 13:11:48 - 1.15 +++ vio.4 24 May 2021 01:48:44 - @@ -27,7 +27,8 @@ The .Nm driver provides support for the .Xr virtio 4 -network interface provided by bhyve, KVM, QEMU, and VirtualBox. +network interface provided by bhyve, KVM, QEMU, VirtualBox, and +.Xr vmd 8 . .Pp Setting the bit 0x2 in the flags disables the RingEventIndex feature. This can be tried as a workaround for possible bugs in host implementations of
relayd client certificate validation
Hi!
Here comes the support for relayd client certificate validation.
Full certificate chain, subject and issuer can be passed over in http headers.
It supports mandatory validation, optional validation(if client chooses to
provide certificate it will be validated) and no validation(cert is passed to
the backend but no validation will happen in relayd).
Part of my sample config.
http protocol test {
match header set "CS_SUBJECT" value "$CLIENT_CERT_SUBJECT"
match header set "CS_ISSUER" value "$CLIENT_CERT_ISSUER"
match header set "CS_CERT" value "$CLIENT_CERT_CHAIN"
pass
tls client ca "/tmp/easyrsa3/pki/ca.crt"
tls { client-insecure, client-optional }
}
This uses code from the patches submitted by Ashe Connor.
Rivo
diff 8c17c73d13a081367dafe608a20fbe1b0ed903ce /home/rix/src
blob - 3e60d63ef52437fed245ed2715e30a0b2bf7956b
file + usr.sbin/relayd/config.c
--- usr.sbin/relayd/config.c
+++ usr.sbin/relayd/config.c
@@ -956,6 +956,15 @@ config_setrelay(struct relayd *env, struct relay *rlay
rlay->rl_conf.name);
return (-1);
}
+ if (rlay->rl_tls_client_ca_fd != -1 &&
+ config_setrelayfd(ps, id, n, 0,
+ rlay->rl_conf.id, RELAY_FD_CLIENTCACERT,
+ rlay->rl_tls_client_ca_fd) == -1) {
+ log_warn("%s: fd passing failed for "
+ "`%s'", __func__,
+ rlay->rl_conf.name);
+ return (-1);
+ }
/* Prevent fd exhaustion in the parent. */
if (proc_flush_imsg(ps, id, n) == -1) {
log_warn("%s: failed to flush "
@@ -989,6 +998,10 @@ config_setrelay(struct relayd *env, struct relay *rlay
close(rlay->rl_s);
rlay->rl_s = -1;
}
+ if (rlay->rl_tls_client_ca_fd != -1) {
+ close(rlay->rl_tls_client_ca_fd);
+ rlay->rl_tls_client_ca_fd = -1;
+ }
if (rlay->rl_tls_cacert_fd != -1) {
close(rlay->rl_tls_cacert_fd);
rlay->rl_tls_cacert_fd = -1;
@@ -1014,6 +1027,10 @@ config_setrelay(struct relayd *env, struct relay *rlay
cert->cert_ocsp_fd = -1;
}
}
+ if (rlay->rl_tls_client_ca_fd != -1) {
+ close(rlay->rl_tls_client_ca_fd);
+ rlay->rl_tls_client_ca_fd = -1;
+ }
return (0);
}
@@ -1036,6 +1053,7 @@ config_getrelay(struct relayd *env, struct imsg *imsg)
rlay->rl_s = imsg->fd;
rlay->rl_tls_ca_fd = -1;
rlay->rl_tls_cacert_fd = -1;
+ rlay->rl_tls_client_ca_fd = -1;
if (ps->ps_what[privsep_process] & CONFIG_PROTOS) {
if (rlay->rl_conf.proto == EMPTY_ID)
@@ -1165,6 +1183,9 @@ config_getrelayfd(struct relayd *env, struct imsg *ims
case RELAY_FD_CAFILE:
rlay->rl_tls_cacert_fd = imsg->fd;
break;
+ case RELAY_FD_CLIENTCACERT:
+ rlay->rl_tls_client_ca_fd = imsg->fd;
+ break;
}
DPRINTF("%s: %s %d received relay fd %d type %d for relay %s", __func__,
blob - 5f7513e788d7ba0615942bd1efee8d9cff6e9941
file + usr.sbin/relayd/parse.y
--- usr.sbin/relayd/parse.y
+++ usr.sbin/relayd/parse.y
@@ -179,7 +179,7 @@ typedef struct {
%token TIMEOUT TLS TO ROUTER RTLABEL TRANSPARENT URL WITH TTL RTABLE
%token MATCH PARAMS RANDOM LEASTSTATES SRCHASH KEY CERTIFICATE PASSWORD ECDHE
%token EDH TICKETS CONNECTION CONNECTIONS CONTEXT ERRORS STATE CHANGES CHECKS
-%token WEBSOCKETS
+%token WEBSOCKETS CLIENT
%token STRING
%token NUMBER
%type context hostname interface table value path
@@ -1353,6 +1353,16 @@ tlsflags : SESSION TICKETS { proto->tickets = 1; }
name->name = $2;
TAILQ_INSERT_TAIL(>tlscerts, name, entry);
}
+ | CLIENT CA STRING {
+ if (strlcpy(proto->tlsclientca, $3,
+ sizeof(proto->tlsclientca)) >=
+ sizeof(proto->tlsclientca)) {
+ yyerror("tlsclientca truncated");
+ free($3);
+ YYERROR;
+ }
+ free($3);
+ }
| NO flag { proto->tlsflags &= ~($2); }
| flag { proto->tlsflags |= $1; }
;
@@ -1374,6 +1384,10 @@ flag : STRING{
$$ = TLSFLAG_CIPHER_SERVER_PREF;
Re: ftpd(8): remove useless islower(3) in upper()
Jan Klemkow writes:
> ping?
>
> On Thu, May 13, 2021 at 04:45:14PM +0200, Jan Klemkow wrote:
>> ping?
>>
>> On Sat, May 01, 2021 at 11:19:56AM +0200, Jan Klemkow wrote:
>> > Hi,
>> >
>> > This cleanup diff, removes a useless if islower(3) from the loop. It is
>> > guarantee by toupper(3) that no character will be changed if its not a
>> > lower one.
>> >
>> > man toupper(3):
>> > The toupper() and toupper_l() functions convert a lower-case letter
>> > to the corresponding upper-case letter. The _toupper() function is
>> > identical to toupper() except that c must be a lower-case letter.
>> >
>> > POSIX:
>> > ...
>> > All other arguments in the domain are returned unchanged.
>> > ...
>> >
>> > OK?
OK gnezdo
>> >
>> > bye,
>> > Jan
>> >
>> > Index: ftpcmd.y
>> > ===
>> > RCS file: /cvs/src/libexec/ftpd/ftpcmd.y,v
>> > retrieving revision 1.69
>> > diff -u -p -r1.69 ftpcmd.y
>> > --- ftpcmd.y 4 Mar 2020 20:17:48 - 1.69
>> > +++ ftpcmd.y 1 May 2021 09:09:46 -
>> > @@ -1435,10 +1435,8 @@ upper(s)
>> > {
>> >char *p;
>> >
>> > - for (p = s; *p; p++) {
>> > - if (islower((unsigned char)*p))
>> > - *p = (char)toupper((unsigned char)*p);
>> > - }
>> > + for (p = s; *p; p++)
>> > + *p = (char)toupper((unsigned char)*p);
>> > }
>> >
>> > static void
>> >
Re: ftpd(8): remove double fflush(3) calls
Jan Klemkow writes:
> ping?
>
> On Thu, May 13, 2021 at 04:44:23PM +0200, Jan Klemkow wrote:
>> ping?
>>
>> On Wed, May 05, 2021 at 04:42:49PM +0200, Jan Klemkow wrote:
>> > Hi,
>> >
>> > The function lreply() already calls fflush(3) on stdout. So, this calls
>> > are useless.
>> >
>> > OK?
OK gnezdo
>> >
>> > bye,
>> > Jan
>> >
>> > Index: ftpd.c
>> > ===
>> > RCS file: /cvs/src/libexec/ftpd/ftpd.c,v
>> > retrieving revision 1.229
>> > diff -u -p -r1.229 ftpd.c
>> > --- ftpd.c 15 Jan 2020 22:06:59 - 1.229
>> > +++ ftpd.c 5 May 2021 14:39:25 -
>> > @@ -568,7 +568,6 @@ main(int argc, char *argv[])
>> >line[strcspn(line, "\n")] = '\0';
>> >lreply(530, "%s", line);
>> >}
>> > - (void) fflush(stdout);
>> >(void) fclose(fp);
>> >reply(530, "System not available.");
>> >exit(0);
>> > @@ -578,7 +577,6 @@ main(int argc, char *argv[])
>> >line[strcspn(line, "\n")] = '\0';
>> >lreply(220, "%s", line);
>> >}
>> > - (void) fflush(stdout);
>> >(void) fclose(fp);
>> >/* reply(220,) must follow */
>> >}
>> > @@ -1078,7 +1076,6 @@ pass(char *passwd)
>> >line[strcspn(line, "\n")] = '\0';
>> >lreply(230, "%s", line);
>> >}
>> > - (void) fflush(stdout);
>> >(void) fclose(fp);
>> >}
>> >free(motd);
>> > @@ -2029,7 +2026,6 @@ cwd(char *path)
>> >line[strcspn(line, "\n")] = '\0';
>> >lreply(250, "%s", line);
>> >}
>> > - (void) fflush(stdout);
>> >(void) fclose(message);
>> >}
>> >ack("CWD");
>> >
>>
Re: Diff for www:OpenBSD/plus69
Fixed. Thanks. On Sat, May 15, 2021 at 9:20 AM wrote: > > Hi, > > Here a diff for www page: OpenBSD/plus69 > > Isn't it a typo? (I'm not sure) > > Right? > > > Index: plus69.html > === > RCS file: /cvs/www/plus69.html,v > retrieving revision 1.3 > diff -u -r1.3 plus69.html > --- plus69.html 5 May 2021 23:58:34 - 1.3 > +++ plus69.html 15 May 2021 12:55:06 - > @@ -186,7 +186,7 @@ > Added a "batch" mode to https://man.openbsd.org/mg.1;>mg(1) > via the "-b" command line option which will initialize a pty, run the > specified file of mg commands and then exit. > > Added https://man.openbsd.org/rpki-client.8;>rpki-client(8) > -V option to show version. > -Removed https://man.openbsd.org/vmd.8;>vwm(8) booting from > kernels in raw/qcow2 images. > +Removed https://man.openbsd.org/vmd.8;>vmd(8) booting from > kernels in raw/qcow2 images. > > Unlocked href="https://man.openbsd.org/sendsyslog.2;>sendsyslog(2). > > -- Dave Voutila Sisu Integrated Services, LLC (m) +1 (617) 538 2151 (web) https://sisu.io
Re: vmd(8): skip inspecting non-udp packets on local ifs
On Sat, May 22, 2021 at 10:20:37AM -0400, Dave Voutila wrote:
> tech@ & krw (since your code in question was imported to vmd),
>
> I found strange behavior running tcpbench(1) to measure the connection
> between a vmd guest and my host, as well as guest-to-guest. In short,
> it's some bogus logic in how vmd tries to intercept dhcp/bootp on local
> interfaces. Diff at the bottom addresses the issue, some background:
>
> Running tcpbench(1) for ~20-30s on my machine, vmd (with -v debug
> logging) barfs a bunch of lines like:
>
> 5 udp packets in 5 too long - dropped
>
> The tcpbench(1) throughput stalls out at that point and reports 0 Mbps
> avg bandwidth measurements.
>
> If anyone wants to reproduce, use an OpenBSD guest and just run:
>
>[host]$ tcpbench -s
> [guest]$ tcpbench -t 180 100.64.x.2
>
> Where 'x' is the appropriate value for your guest's local interface.
>
> reyk@ imported packet.c from dhclient(8), but there's no validation that
> the packet being inspected is an IP/UDP packet vs. IP/TCP, leading to
> bogus logic related to inspecing UDP header attributes. In dhclient(8),
> the decode_udp_ip_header function is used in a place where a bpf capture
> buffer has already made sure it's a UDP packet (see sbin/dhclient/bpf.c).
>
> In addition, there was a lot of stateful counting and checking we just
> don't need in vmd(8), so I've ripped that out as well. It makes no sense
> in this context.
>
> OK?
>
ok mlarkin
>
> Index: packet.c
> ===
> RCS file: /cvs/src/usr.sbin/vmd/packet.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 packet.c
> --- packet.c 19 Apr 2017 15:38:32 - 1.1
> +++ packet.c 22 May 2021 14:15:09 -
> @@ -220,12 +220,6 @@ decode_udp_ip_header(unsigned char *buf,
> unsigned char *data;
> u_int32_t ip_len;
> u_int32_t sum, usum;
> - static unsigned int ip_packets_seen;
> - static unsigned int ip_packets_bad_checksum;
> - static unsigned int udp_packets_seen;
> - static unsigned int udp_packets_bad_checksum;
> - static unsigned int udp_packets_length_checked;
> - static unsigned int udp_packets_length_overflow;
> int len;
>
> /* Assure that an entire IP header is within the buffer. */
> @@ -236,17 +230,11 @@ decode_udp_ip_header(unsigned char *buf,
> return (-1);
>
> ip = (struct ip *)(buf + offset);
> - ip_packets_seen++;
> + if (ip->ip_p != IPPROTO_UDP)
> + return (-1);
>
> /* Check the IP header checksum - it should be zero. */
> if (wrapsum(checksum(buf + offset, ip_len, 0)) != 0) {
> - ip_packets_bad_checksum++;
> - if (ip_packets_seen > 4 && ip_packets_bad_checksum != 0 &&
> - (ip_packets_seen / ip_packets_bad_checksum) < 2) {
> - log_info("%u bad IP checksums seen in %u packets",
> - ip_packets_bad_checksum, ip_packets_seen);
> - ip_packets_seen = ip_packets_bad_checksum = 0;
> - }
> return (-1);
> }
>
> @@ -274,7 +262,6 @@ decode_udp_ip_header(unsigned char *buf,
> if (buflen < offset + ip_len + sizeof(*udp))
> return (-1);
> udp = (struct udphdr *)(buf + offset + ip_len);
> - udp_packets_seen++;
>
> /* Assure that the entire UDP packet is within the buffer. */
> if (buflen < offset + ip_len + ntohs(udp->uh_ulen))
> @@ -286,20 +273,8 @@ decode_udp_ip_header(unsigned char *buf,
>* UDP header and the data. If the UDP checksum field is zero,
>* we're not supposed to do a checksum.
>*/
> - udp_packets_length_checked++;
> len = ntohs(udp->uh_ulen) - sizeof(*udp);
> if ((len < 0) || (len + data > buf + buflen)) {
> - udp_packets_length_overflow++;
> - if (udp_packets_length_checked > 4 &&
> - udp_packets_length_overflow != 0 &&
> - (udp_packets_length_checked /
> - udp_packets_length_overflow) < 2) {
> - log_info("%u udp packets in %u too long - dropped",
> - udp_packets_length_overflow,
> - udp_packets_length_checked);
> - udp_packets_length_overflow =
> - udp_packets_length_checked = 0;
> - }
> return (-1);
> }
> if (len + data != buf + buflen)
> @@ -313,15 +288,7 @@ decode_udp_ip_header(unsigned char *buf,
> 2 * sizeof(ip->ip_src),
> IPPROTO_UDP + (u_int32_t)ntohs(udp->uh_ulen);
>
> - udp_packets_seen++;
> if (usum && usum != sum) {
> - udp_packets_bad_checksum++;
> - if (udp_packets_seen > 4 && udp_packets_bad_checksum != 0 &&
> - (udp_packets_seen / udp_packets_bad_checksum) < 2) {
> - log_info("%u bad udp checksums in %u packets",
> -
Re: amd64: softintr_dispatch: remove kernel lock
On Sat, May 22, 2021 at 02:23:57PM +, Visa Hankala wrote: > On Sat, May 22, 2021 at 02:33:47PM +0200, Mark Kettenis wrote: > > > Date: Sat, 22 May 2021 11:11:38 + > > > From: Visa Hankala > > > > > > On Wed, May 19, 2021 at 05:11:09PM -0500, Scott Cheloha wrote: > > > > Hi, > > > > > > > > visa@ says I need to unlock softintr_dispatch() before I can > > > > unlock softclock(), so let's do that. > > > > > > > > Additionally, when we call softintr_disestablish() we want to wait for > > > > the underlying softintr handle to finish running if it is running. > > > > > > > > We can start with amd64. > > > > > > > > I think this approach will work: > > > > > > > > - Keep a pointer to the running softintr, if any, in the queue. NULL > > > > the pointer when we return from sih_func(). > > > > > > > > - Take/release the kernel lock if the SI_MPSAFE flag is present when > > > > we enter/leave sih_func(). > > > > > > > > - If the handle is running when you call softintr_disestablish(), spin > > > > until the handle isn't running anymore and retry. > > > > > > > > There is no softintr manpage but I think it is understood that > > > > softintr_disestablish() is only safe to call from a process context, > > > > otherwise you may deadlock. Maybe we should do splassert(IPL_NONE)? > > > > > > > > We could probably sleep here instead of spinning. We'd have to change > > > > every softintr_disestablish() implementation to do that, though. > > > > Otherwise you'd have different behavior on different platforms. > > > > > > I think your diff does not pay enough attention to the fact that soft > > > interrupts are handled by all CPUs. I think the diff that I posted > > > a while ago [1] is better in that respect. > > > > > > Two biggest things that I do not like in my original diff are > > > synchronization of handler execution, and use of the SMR barrier. > > > > > > [1] https://marc.info/?l=openbsd-tech=162092714911609 > > > > > > The kernel lock has guaranteed that at most one CPU is able to run > > > a given soft interrupt handler at a time. My diff used a mutex to > > > prevent concurrent execution. However, it is wasteful to spin. It would > > > be more economical to let the current runner of the handler re-execute > > > the code. > > > > > > The SMR barrier in softintr_disestablish() was a trick to drain any > > > pending activity. However, it made me feel uneasy because I have not > > > checked every caller of softintr_disestablish(). My main worry is not > > > the latency but unexpected side effects. > > > > > > Below is a revised diff that improves the above two points. > > > > > > When a soft interrupt handler is scheduled, it is assigned to a CPU. > > > That CPU will keep running the handler as long as there are pending > > > requests. Once all pending requests have been drained, the CPU > > > relinquishes its hold of the handler. This provides natural > > > serialization. > > > > > > Now softintr_disestablish() uses spinning for draining activity. > > > I still have slight qualms about this, though, because the feature > > > has not been so explicit before. Integration with witness(4) might be > > > in order. > > > > > > softintr_disestablish() uses READ_ONCE() to enforce reloading of the > > > value in the busy-wait loop. This way the variable does not need to be > > > volatile. (As yet another option, CPU_BUSY_CYCLE() could always > > > imply memory clobbering, which should make an optimizing compiler > > > redo the load.) For consistency with this READ_ONCE(), WRITE_ONCE() is > > > used whenever the variable is written, excluding the initialization. > > > > > > The patch uses a single mutex for access serialization. The old code > > > has used one mutex per each soft IPL level, but I am not sure how > > > useful that has been. I think it would be better to have a separate > > > mutex for each CPU. However, the increased code complexity might not > > > be worthwhile at the moment. Even having the per-CPU queues has > > > a whiff of being somewhat overkill. > > > > A few comments: > > > > * Looking at amd64 in isolation does not make sense. Like a lot of MD > > code in OpenBSD the softintr code was copied from whatever > > Net/FreeBSD had at the time, with no attempt at unification (it > > works, check it in, don't go back to clean it up). However, with > > powerpc64 and riscv64 we try to do things a little bit better in > > that area. So arm64, powerpc64 and riscv64 share the same softintr > > implementation that already implements softintr_establish_flags() > > with SOFTINTR_ESTABLISH_MPSAFE. Now we haven't used that flag > > anywhere in our tree yet, so the code might be completely busted. > > But it may make a lot of sense to migrate other architectures to the > > same codebase. > > I know that the implementations should be unified, or made machine > independent as far as possible. I have focused on amd64's code to get > the MP-safe processing
Re: smtp: more tls options
On Sat, May 22, 2021 at 04:08:55PM +0200, Eric Faurot wrote: > The new -T option in smtp(1) allows to plug more TLS parameters easily. > For completeness and consistency, this diff adds the following: > > cafile=: override the default root certificates > nosni: disable SNI completely > noverify: synonym for -C that can be recycled > servername=: synonym for -S (undocumented) that can be recycled too ok tb
