rc.shutdown.8: document stopping vmd(8)
Came here after reading /etc/rc wrt. the shutdown sequence. Feedback? Index: rc.shutdown.8 === RCS file: /cvs/src/share/man/man8/rc.shutdown.8,v retrieving revision 1.16 diff -u -p -r1.16 rc.shutdown.8 --- rc.shutdown.8 16 May 2020 16:58:12 - 1.16 +++ rc.shutdown.8 11 May 2023 02:34:44 - @@ -54,6 +54,9 @@ defined in the .Va pkg_scripts variable in .Xr rc.conf.local 8 , +as well as +.Xr vmd 8 , +in that order, by passing them the .Cm stop argument.
Re: syscall(SYS_sysctl) broken in 7.3
On Wed, May 10, 2023 at 1:29 PM Alexander Bluhm wrote: > We use Perl syscall(2) function to implement sysctl(2) system calls. > This is broken since OpenBSD 7.3. A sample program looks like this: > ... > kdump shows two problems: > 1. The mib is not printed correctly. > 2. The final argument newlen should be 0x10, but is 0x8891aa893c5. > > 30762 perl CALL (via syscall) > sysctl(538970683.538976288.538976288.1718165536,0,0,0x8891d2e1de0,0x8891aa893c5) > 30762 perl RET sysctl -1 errno 22 Invalid argument > > 1. The syscall code now contains the KTRC_CODE_SYSCALL flag, but > the kernel checks code == SYS_sysctl. So the mib is not added to > ktrace output. Fix is easy by using KTRC_CODE_MASK. > ok guenther@ on the first chunk, the ktrsyscall() change. The flag is only passed to ktrsyscall(), not ktrsysret(), so the second chunk of your diff is unnecessary. > 2. Was introdced by this commit in libc. > > revision 1.21 > date: 2023/01/11 01:55:17; author: mortimer; state: Exp; lines: +24 > -13; commitid: 72pYktDvmJhq7OyF; > Add retguard to amd64 syscalls. > > Since we got rid of padded syscalls we have enough registers to do this. > > ok deraadt@ ok kettenis@ > > It assumes that syscalls only have 6 parameters, which is not true > if syscall(2) adds the syscall number. Now the final argument > contains retguard values from the stack. > This is why we can't have nice things. > The easies way to fix this without reverting retguard for all > syscalls, is to use revision 1.20 of SYS.h in libc for syscall.S. > Just manually include the old code instead of current SYS.h. > > I am aware that syscall(2) should go way, but currently I need it. > > ok? > Ick. How about this instead, which preserves retguard protection for syscall(2) and doesn't copy all of SYS.h? Index: lib/libc/arch/amd64/sys/syscall.S === retrieving revision 1.8 diff -u -p -r1.8 syscall.S --- lib/libc/arch/amd64/sys/syscall.S 7 May 2016 19:05:21 - 1.8 +++ lib/libc/arch/amd64/sys/syscall.S 11 May 2023 02:13:20 - @@ -39,4 +39,18 @@ #include "SYS.h" -RSYSCALL(syscall) +SYSENTRY(syscall) + RETGUARD_SETUP(_thread_sys_syscall, r11) +#ifdef _RET_PROTECTOR + pushq 8(%rsp) /* repush 6th argument */ +#endif + RETGUARD_PUSH(r11) + SYSTRAP(syscall) + HANDLE_ERRNO; + RETGUARD_POP(r11) +#ifdef _RET_PROTECTOR + addq$8,%rsp /* pop 6th argument */ +#endif + RETGUARD_CHECK(_thread_sys_syscall, r11) + ret +SYSCALL_END(syscall)
Re: Status of Virtual Function driver for Intel 82599 series port?
On 4/30/23 04:04, Paul B. Henson wrote:
> https://marc.info/?l=openbsd-tech=167160269008839=2
>
> The port doesn't appear to be merged yet, and there's no activity on the
> thread since December, so I was just wondering what the current status
> of this is? If there's any further testing needed I have a system I can
> spin up test vm's on.
Hi, I believe my patch works on ESXi and Linux qemu. I'm looking for a
reviewer. It's welcome to testing and reporting the results if it works
or fails to work.
> Also, I tried downloading the patch from the mailing list archive and it
> seems corrupted and won't apply. Could someone possibly forward me
> directly the latest version of the patch?
I rebased my patch for OpenBSD current. See the below patch of this mail.
Install procedure:
```
Make sure that OpenBSD current source is written in /usr/src.
```
# cd /usr/src
# patch -p1 -i /somewhre/ixv.patch
# cd sys/dev/pci
# make
# cd /usr/src/sys/arch/amd64/compile/GENERIC.MP
# make obj
# make config
# make -j 4
# make install
# reboot
Known limitations:
1. Do not use 'ifconfig lladdr' on ESXi.
Changing link local address is not permitted on ESXi.
If it is changed, the interface cannot be usable any more.
Need to reboot the VM.
Link local address can be changed by ESXi user interface.
On Linux qemu, 'ifconfig lladdr' works.
2. MTU 9000 is required for 10Gbps performance.
The default MTU size 1500 is too small for 10Gbps link for now.
diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC
index c8e4ec8284e..2ad357f9c1b 100644
--- a/sys/arch/amd64/conf/GENERIC
+++ b/sys/arch/amd64/conf/GENERIC
@@ -524,6 +524,7 @@ msk*at mskc?# each port of
above
em*at pci? # Intel Pro/1000 ethernet
ixgb* at pci? # Intel Pro/10Gb ethernet
ix*at pci? # Intel 82598EB 10Gb ethernet
+ixv* at pci? # Virtual Function of Intel 82598EB
myx* at pci? # Myricom Myri-10G 10Gb ethernet
oce* at pci? # Emulex OneConnect 10Gb ethernet
txp* at pci? # 3com 3CR990
diff --git a/sys/dev/pci/files.pci b/sys/dev/pci/files.pci
index 101ed502e76..72c8b485938 100644
--- a/sys/dev/pci/files.pci
+++ b/sys/dev/pci/files.pci
@@ -350,13 +350,19 @@ file dev/pci/ixgb_hw.c ixgb
# Intel 82598 10GbE
device ix: ether, ifnet, ifmedia, intrmap, stoeplitz
attach ix at pci
-file dev/pci/if_ix.c ix
-file dev/pci/ixgbe.c ix
-file dev/pci/ixgbe_82598.c ix
-file dev/pci/ixgbe_82599.c ix
-file dev/pci/ixgbe_x540.cix
-file dev/pci/ixgbe_x550.cix
-file dev/pci/ixgbe_phy.c ix
+file dev/pci/if_ix.c ix | ixv
+file dev/pci/ixgbe.c ix | ixv
+file dev/pci/ixgbe_82598.c ix | ixv
+file dev/pci/ixgbe_82599.c ix | ixv
+file dev/pci/ixgbe_x540.cix | ixv
+file dev/pci/ixgbe_x550.cix | ixv
+file dev/pci/ixgbe_phy.c ix | ixv
+
+# Virtual Function of i82599.
+device ixv: ether, ifnet, ifmedia, intrmap, stoeplitz
+attach ixv at pci
+file dev/pci/if_ixv.cixv
+file dev/pci/ixgbe_vf.c ixv
# Intel Ethernet 700 Series
device ixl: ether, ifnet, ifmedia, intrmap, stoeplitz
diff --git a/sys/dev/pci/if_ix.c b/sys/dev/pci/if_ix.c
index 870c3349fb3..24397a01a9d 100644
--- a/sys/dev/pci/if_ix.c
+++ b/sys/dev/pci/if_ix.c
@@ -507,7 +507,7 @@ ixgbe_start(struct ifqueue *ifq)
* hardware that this frame is available to transmit.
*/
if (post)
- IXGBE_WRITE_REG(>hw, IXGBE_TDT(txr->me),
+ IXGBE_WRITE_REG(>hw, txr->tail,
txr->next_avail_desc);
}
@@ -705,7 +705,7 @@ ixgbe_watchdog(struct ifnet * ifp)
for (i = 0; i < sc->num_queues; i++, txr++) {
printf("%s: Queue(%d) tdh = %d, hw tdt = %d\n", ifp->if_xname,
i,
IXGBE_READ_REG(hw, IXGBE_TDH(i)),
- IXGBE_READ_REG(hw, IXGBE_TDT(i)));
+ IXGBE_READ_REG(hw, sc->tx_rings[i].tail));
printf("%s: TX(%d) Next TX to Clean = %d\n", ifp->if_xname,
i, txr->next_to_clean);
}
@@ -825,7 +825,7 @@ ixgbe_init(void *arg)
msec_delay(1);
}
IXGBE_WRITE_FLUSH(>hw);
- IXGBE_WRITE_REG(>hw, IXGBE_RDT(i), rxr->last_desc_filled);
+ IXGBE_WRITE_REG(>hw, rxr[i].tail, rxr->last_desc_filled);
}
/* Set up VLAN support and filter */
@@ -2358,9 +2358,12 @@ ixgbe_initialize_transmit_units(struct ix_softc *sc)
IXGBE_WRITE_REG(hw, IXGBE_TDLEN(i),
sc->num_tx_desc * sizeof(struct ixgbe_legacy_tx_desc));
+
Re: vmm/vmd: use anon shared mappings for devices
On Tue, May 09, 2023 at 06:12:55AM -0400, Dave Voutila wrote:
> tech@,
>
> The diff below adds a new ioctl for vmm(4) that allows an emulated
> device process request vmm(4) enter a shared mapping in its vmspace so
> it can access guest memory without using a shared mapping backed by a
> named file.
>
> Similar to the vm creation ioctl (VMM_IOC_CREATE), the caller requires
> the "vmm" and "proc" pledge(2) promises. This allows the emulated
> devices to do this setup early and drop these promises back down to just
> "stdio" before any device emulation occurs.
>
> Feel free to skip to the diff (the regress change shows how it works in
> a simplified case) or continue reading for reasoning behind this
> change. I share this primarily for testers and feedback from other devs
> while mlarkin@ reviews.
>
> To test:
>
> 1. apply diff
> 2. build and install new kernel
> 3. copy or symlink new vmm.h into /usr/include/dev/vmm/
> 4. build and reinstall vmd (no changes for vmctl needed)
>
> You should see no change during vm usage, however you should now see no
> change in /tmp consumption while unmounting things like NFS mounts or
> usb disks. Read on for details.
>
> ...
>
> vmd(8) began emulating virtio network and block devices in subprocesses
> with a commit I made at the recent hackathon in Morocco. It relies on
> creating shared memory mappings using shm_mkstemp(3) and passing file
> descriptors to the fork/exec'd child processes.
>
> I've since received reports that using named mappings for shared memory
> is having 2 negative impacts:
>
> 1. increased overhead during vm teardown, often making systems
>unresponsive (this is my conclusion based on only minimal evidence)
>
> 2. unmounting any device on the host while a vm is running causes some
>guest memory to be flushed to disk (the backing file is already
>unlinked, so not visible to other processes).
>
> (2) can cause /tmp to fill up or introduce failure conditions I'm not
> sure we can recover from in vmd. It also has implications for other
> services on the host.
>
> I don't own a fireproof suit that fits...so I'm not about to wade into
> the VFS & UVM layers to figure out if (1) or (2) can be mitigated or
> fixed on their own.
>
> One idea was to implement what FreeBSD borrowed from Linux in their
> forever quest to become LinuxBSD: memfd_create(2) [1].
>
> I took one look and decided this was not the time for me to be trying to
> land a new syscall primarily for vmd (and some ports) and went another
> route.
>
> [1] https://man7.org/linux/man-pages/man2/memfd_create.2.html
>
> -dv
>
This does fix the unexpected shm issues. Thanks!
Diff reads ok to me, go for it when you are happy with the test results.
-ml
>
> diff refs/heads/master refs/heads/vmm-mapshare
> commit - cec1ace2d4d21c85f4c8bacc2dd971721bf6b694
> commit + 8f533c371094c044b0127d468be5feaaf775811b
> blob - f221b58f75c4eb01a3a04ae45c7cdb066b11361a
> blob + 0e6f5ff858c51bd9707c657b154b0df1f8944c3b
> --- regress/sys/arch/amd64/vmm/vcpu.c
> +++ regress/sys/arch/amd64/vmm/vcpu.c
> @@ -83,6 +83,7 @@ main(int argc, char **argv)
> struct vm_resetcpu_paramsvresetp;
> struct vm_run_params vrunp;
> struct vm_terminate_params vtp;
> + struct vm_sharemem_paramsvsp;
>
> struct vm_mem_range *vmr;
> int fd, ret = 1;
> @@ -127,8 +128,9 @@ main(int argc, char **argv)
> ((uint8_t*)p)[j + 1] = PCKBC_AUX;
> }
> vmr->vmr_va = (vaddr_t)p;
> - printf("mapped region %zu: { gpa: 0x%08lx, size: %lu }\n",
> - i, vmr->vmr_gpa, vmr->vmr_size);
> + printf("created mapped region %zu: { gpa: 0x%08lx, size: %lu,"
> + " hva: 0x%lx }\n", i, vmr->vmr_gpa, vmr->vmr_size,
> + vmr->vmr_va);
> }
>
> if (ioctl(fd, VMM_IOC_CREATE, ) == -1)
> @@ -136,8 +138,55 @@ main(int argc, char **argv)
> printf("created vm %d named \"%s\"\n", vcp.vcp_id, vcp.vcp_name);
>
> /*
> - * 2. Check that our VM exists.
> + * 2. Check we can create shared memory mappings.
>*/
> + memset(, 0, sizeof(vsp));
> + vsp.vsp_nmemranges = vcp.vcp_nmemranges;
> + memcpy(_memranges, _memranges,
> + sizeof(vsp.vsp_memranges));
> + vsp.vsp_vm_id = vcp.vcp_id;
> +
> + /* Find some new va ranges... */
> + for (i = 0; i < vsp.vsp_nmemranges; i++) {
> + vmr = _memranges[i];
> + p = mmap(NULL, vmr->vmr_size, PROT_READ | PROT_WRITE,
> + MAP_PRIVATE | MAP_ANON, -1, 0);
> + if (p == MAP_FAILED)
> + err(1, "mmap");
> + vmr->vmr_va = (vaddr_t)p;
> + }
> +
> + /* Release our mappings so vmm can replace them. */
> + for (i = 0; i < vsp.vsp_nmemranges; i++) {
> + vmr = _memranges[i];
> + munmap((void*)vmr->vmr_va, vmr->vmr_size);
> + }
> +
> +
syscall(SYS_sysctl) broken in 7.3
Hi,
We use Perl syscall(2) function to implement sysctl(2) system calls.
This is broken since OpenBSD 7.3. A sample program looks like this:
#!/usr/bin/perl
use constant SYS_sysctl => 202;
# net.inet6.ip6.soiikey
my @mib = (4, 24, 41, 54);
my $miblen = scalar(@mib);
my $mib = pack("i$miblen", @mib);
$new = pack("H32", "0123456789abcdef0123456789abcdef");
$newlen = length($new);
syscall(SYS_sysctl(), $mib, $miblen, 0, 0, $new, $newlen);
kdump shows two problems:
1. The mib is not printed correctly.
2. The final argument newlen should be 0x10, but is 0x8891aa893c5.
30762 perl CALL (via syscall)
sysctl(538970683.538976288.538976288.1718165536,0,0,0x8891d2e1de0,0x8891aa893c5)
30762 perl RET sysctl -1 errno 22 Invalid argument
1. The syscall code now contains the KTRC_CODE_SYSCALL flag, but
the kernel checks code == SYS_sysctl. So the mib is not added to
ktrace output. Fix is easy by using KTRC_CODE_MASK.
2. Was introdced by this commit in libc.
revision 1.21
date: 2023/01/11 01:55:17; author: mortimer; state: Exp; lines: +24 -13;
commitid: 72pYktDvmJhq7OyF;
Add retguard to amd64 syscalls.
Since we got rid of padded syscalls we have enough registers to do this.
ok deraadt@ ok kettenis@
It assumes that syscalls only have 6 parameters, which is not true
if syscall(2) adds the syscall number. Now the final argument
contains retguard values from the stack.
The easies way to fix this without reverting retguard for all
syscalls, is to use revision 1.20 of SYS.h in libc for syscall.S.
Just manually include the old code instead of current SYS.h.
I am aware that syscall(2) should go way, but currently I need it.
ok?
bluhm
Index: sys/kern/kern_ktrace.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/kern/kern_ktrace.c,v
retrieving revision 1.111
diff -u -p -r1.111 kern_ktrace.c
--- sys/kern/kern_ktrace.c 16 Feb 2023 08:50:57 - 1.111
+++ sys/kern/kern_ktrace.c 10 May 2023 16:28:39 -
@@ -160,7 +160,7 @@ ktrsyscall(struct proc *p, register_t co
u_int nargs = 0;
int i;
- if (code == SYS_sysctl) {
+ if ((code & KTRC_CODE_MASK) == SYS_sysctl) {
/*
* The sysctl encoding stores the mib[]
* array because it is interesting.
@@ -198,7 +198,7 @@ ktrsysret(struct proc *p, register_t cod
ktp.ktr_error = error;
if (error)
len = 0;
- else if (code == SYS_lseek)
+ else if ((code & KTRC_CODE_MASK) == SYS_lseek)
/* the one exception: lseek on ILP32 needs more */
len = sizeof(long long);
else
Index: lib/libc/arch/amd64/sys/syscall.S
===
RCS file: /data/mirror/openbsd/cvs/src/lib/libc/arch/amd64/sys/syscall.S,v
retrieving revision 1.8
diff -u -p -r1.8 syscall.S
--- lib/libc/arch/amd64/sys/syscall.S 7 May 2016 19:05:21 - 1.8
+++ lib/libc/arch/amd64/sys/syscall.S 10 May 2023 19:29:17 -
@@ -37,6 +37,80 @@
#include
-#include "SYS.h"
+#include "DEFS.h"
+#include
+
+/* offsetof(struct tib, tib_errno) - offsetof(struct tib, __tib_tcb) */
+#defineTCB_OFFSET_ERRNO32
+
+#define SYSTRAP(x) movl $(SYS_ ## x),%eax; movq %rcx, %r10; syscall
+
+#define SYSENTRY(x)\
+ SYSENTRY_HIDDEN(x); \
+ WEAK_ALIAS(x, _thread_sys_##x)
+#define SYSENTRY_HIDDEN(x) \
+ ENTRY(_thread_sys_ ## x)
+
+#defineSYSCALL_END_HIDDEN(x)
\
+ END(_thread_sys_ ## x); \
+ _HIDDEN_FALIAS(x,_thread_sys_##x); \
+ END(_HIDDEN(x))
+#defineSYSCALL_END(x) SYSCALL_END_HIDDEN(x); END(x)
+
+
+#define SET_ERRNO \
+ movl%eax,%fs:(TCB_OFFSET_ERRNO);\
+ movq$-1, %rax
+#define HANDLE_ERRNO \
+ jnc 99f;\
+ SET_ERRNO; \
+ 99:
+
+#define _SYSCALL_NOERROR(x,y) \
+ SYSENTRY(x);\
+ SYSTRAP(y)
+#define _SYSCALL_HIDDEN_NOERROR(x,y) \
+ SYSENTRY_HIDDEN(x); \
+ SYSTRAP(y)
+
+#define SYSCALL_NOERROR(x) \
+ _SYSCALL_NOERROR(x,x)
+
+#define SYSCALL_HIDDEN(x) \
+ _SYSCALL_HIDDEN_NOERROR(x,x);
Re: rpki-client: provide more diagnostics to the operator
> $ doas rpki-client -t /etc/rpki/ripe.tal -H rpki.ripe.net -H
> chloe.sobornost.net
> rpki-client:
> .rrdp/436FC6BD7B32853E42FCE5FD95B31D5E3EC1C32C46B7518C2067D568E7EAC119/chloe.sobornost.net/rpki/RIPE-nljobsnijders/cb/5EjPZ8Kw2_h5hRqKpwmjdnq7Tq8.roa:
> bad file digest for 5EjPZ8Kw2_h5hRqKpwmjdnq7Tq8.roa (expected:
> NFzQYsvSF+8jLhUXGuVwQ4NNoMyfrJnJbW6DNmbtXRc=, got
> dc0ZvFHMNWzESwFdWRLnde2EjRt5+hkxdLIc5tgznDo=)
> rpki-client:
> .rrdp/436FC6BD7B32853E42FCE5FD95B31D5E3EC1C32C46B7518C2067D568E7EAC119/chloe.sobornost.net/rpki/RIPE-nljobsnijders/cb/t7xg6ZtXdcYhy-YGTMk_ONTD31E.mft#052F:
> missing 5EjPZ8Kw2_h5hRqKpwmjdnq7Tq8.roa
This is a bit much hex/base64 noise for my taste, to be honest, but I
guess I can live with it. Some comments below.
> Index: validate.c
> ===
> RCS file: /cvs/src/usr.sbin/rpki-client/validate.c,v
> retrieving revision 1.60
> diff -u -p -r1.60 validate.c
> --- validate.c9 May 2023 10:34:32 - 1.60
> +++ validate.c10 May 2023 17:34:57 -
> @@ -211,18 +211,22 @@ valid_roa(const char *fn, struct cert *c
> * Returns 1 if hash matched, 0 otherwise. Closes fd when done.
> */
> int
> -valid_filehash(int fd, const char *hash, size_t hlen)
> +valid_filehash(int fd, const char *loc, const char *fn,
> +const unsigned char *hash, size_t hlen)
Almost all functions have the fn first. I'd prefer
valid_filehash(loc, fn, fd, hash, len)
I suppose the loc is necessary, unfortunately.
> {
> - SHA256_CTX ctx;
> - charfilehash[SHA256_DIGEST_LENGTH];
> - charbuffer[8192];
> - ssize_t nr;
> + SHA256_CTX ctx;
> + unsigned charfilehash[SHA256_DIGEST_LENGTH];
> + char buffer[8192];
> + char*expected = NULL, *computed = NULL;
> + ssize_t nr;
> + int rc = 0;
>
> - if (hlen != sizeof(filehash))
> + if (hlen != SHA256_DIGEST_LENGTH)
> errx(1, "bad hash size");
>
> + /* non-existing file, error will be printed elsewhere (if needed) */
> if (fd == -1)
> - return 0;
> + goto out;
None of the changes above are needed. I'd prefer to leave all that alone.
>
> SHA256_Init();
> while ((nr = read(fd, buffer, sizeof(buffer))) > 0)
> @@ -230,9 +234,21 @@ valid_filehash(int fd, const char *hash,
> close(fd);
> SHA256_Final(filehash, );
>
> - if (memcmp(hash, filehash, sizeof(filehash)) != 0)
> - return 0;
> - return 1;
> + if (memcmp(hash, filehash, SHA256_DIGEST_LENGTH) != 0) {
Again, try to keep the code as it was as far as possible. Also, you could
declare the new variables here (initialization to NULL is unnecessary):
if (memcmp(hash, filehash, sizeof(filehash)) != 0) {
char *expected, *computed;
> + if (base64_encode(hash, hlen, ) == -1)
> + errx(1, "base64_encode failed");
> + if (base64_encode(filehash, hlen, ) == -1)
> + errx(1, "base64_encode failed");
> + warnx("%s: bad file digest for %s (expected: %s, got %s)",
> + loc, fn, expected, computed);
and finish like this
free(expected);
free(computed);
return 0;
}
return 1;
}
Then the below churn goes away, too.
> + goto out;
> + }
> +
> + rc = 1;
> + out:
> + free(expected);
> + free(computed);
> + return rc;
> }
>
> /*
Re: seperate LRO/TSO flags
On Wed, 10 May 2023 20:55:24 +0200, Jan Klemkow wrote: > For tcprecvoffload and ix(4) it's not possible to enable/disable it per > address family. Its just one flag for the hardware. > > For tcpsendoffload its possible, but I won't do that till its necessary. > > Why would you want to differentiate the address families here? I was mostly just curious as I see FreeBSD seems to support this. That made we wonder if there is hardware that only supports offloading for IPv4. - todd
Re: seperate LRO/TSO flags
On Wed, May 10, 2023 at 11:13:04AM -0600, Todd C. Miller wrote: > On Wed, 10 May 2023 19:03:58 +0200, Jan Klemkow wrote: > > This diff introduces separate flags for TCP offloading. We split this > > into LRO (large receive offloading) and TSO (TCP segmentation > > offloading). Thus, we are able to turn it on/off separately. > > > > For ifconfig(8) we use "tcprecvoffload" and "tcpsendoffload". So, the > > user has a better insight of what this features are doing. > > Is it possible to control these at the address family level? In > other words, is it possible to enable "tcprecvoffload" and > "tcpsendoffload" for inet but not inet6 or vice versa? For tcprecvoffload and ix(4) it's not possible to enable/disable it per address family. Its just one flag for the hardware. For tcpsendoffload its possible, but I won't do that till its necessary. Why would you want to differentiate the address families here? bye, Jan
Re: [patch] Discontinued Toshiba dynadock lines for usbdevs and udl driver
> Good Day, > > https://uk.dynabook.com/discontinued-products/pa3542e-2prp/ > > one more device with old (probably DL-160, but unsure so leaving > DLUNK) DisplayLink chip. works ok. Patch applied, thanks! Miod
rpki-client: provide more diagnostics to the operator
Hi folks,
Without this changeset, rpki-client will display diagnostic information
about missing files like so:
$ doas rpki-client -t /etc/rpki/lacnic.tal -H repository.lacnic.net
rpki-client:
repository.lacnic.net/rpki/lacnic/a0c4b4a0-6417-4a7c-8758-9e6f4b0e9679/9783ac9bad2b7b922f648c90e881bf44978069ad.mft:
bad message digest for aa78fd79d9a4dc5b9456cc52ce73dba02a1eabe4.roa
rpki-client:
repository.lacnic.net/rpki/lacnic/a0c4b4a0-6417-4a7c-8758-9e6f4b0e9679/9783ac9bad2b7b922f648c90e881bf44978069ad.mft:
bad message digest for d5dc4167b95f994ae118a5c41a0e70425bc3e3f8.roa
With the below changeset applied, it'll show a more intuitive error, and
also print the manifestNumber (after the mft filename, prefixed with #)
to aid debugging efforts (aka "when did this go wrong")
rpki-client:
.rrdp/4B9F4F9A8FFDEB194969CF392CB513D1C7743232CCD8794BF317D0969B7CD660/repository.lacnic.net/rpki/lacnic/a0c4b4a0-6417-4a7c-8758-9e6f4b0e9679/9783ac9bad2b7b922f648c90e881bf44978069ad.mft#0A1A:
missing aa78fd79d9a4dc5b9456cc52ce73dba02a1eabe4.roa
rpki-client:
.rrdp/4B9F4F9A8FFDEB194969CF392CB513D1C7743232CCD8794BF317D0969B7CD660/repository.lacnic.net/rpki/lacnic/a0c4b4a0-6417-4a7c-8758-9e6f4b0e9679/9783ac9bad2b7b922f648c90e881bf44978069ad.mft#0A1A:
missing d5dc4167b95f994ae118a5c41a0e70425bc3e3f8.roa
Additionally, in cases where the file is corrupted (not missing), the
expected and the computed hashes are printed:
$ doas rpki-client -t /etc/rpki/ripe.tal -H rpki.ripe.net -H
chloe.sobornost.net
rpki-client:
.rrdp/436FC6BD7B32853E42FCE5FD95B31D5E3EC1C32C46B7518C2067D568E7EAC119/chloe.sobornost.net/rpki/RIPE-nljobsnijders/cb/5EjPZ8Kw2_h5hRqKpwmjdnq7Tq8.roa:
bad file digest for 5EjPZ8Kw2_h5hRqKpwmjdnq7Tq8.roa (expected:
NFzQYsvSF+8jLhUXGuVwQ4NNoMyfrJnJbW6DNmbtXRc=, got
dc0ZvFHMNWzESwFdWRLnde2EjRt5+hkxdLIc5tgznDo=)
rpki-client:
.rrdp/436FC6BD7B32853E42FCE5FD95B31D5E3EC1C32C46B7518C2067D568E7EAC119/chloe.sobornost.net/rpki/RIPE-nljobsnijders/cb/t7xg6ZtXdcYhy-YGTMk_ONTD31E.mft#052F:
missing 5EjPZ8Kw2_h5hRqKpwmjdnq7Tq8.roa
The above previously would be 1 error line, but now two lines are shown:
1 for the fact that a given ROA is corrupted and 1 as a result of the
above the manifest that's now invalidated (RFC 9286). I think two
messages is appropriate in such situations.
OK?
Kind regards,
Job
Index: extern.h
===
RCS file: /cvs/src/usr.sbin/rpki-client/extern.h,v
retrieving revision 1.181
diff -u -p -r1.181 extern.h
--- extern.h9 May 2023 10:34:32 - 1.181
+++ extern.h10 May 2023 17:34:57 -
@@ -681,7 +681,8 @@ int valid_ta(const char *, struct auth
const struct cert *);
int valid_cert(const char *, struct auth *, const struct cert *);
int valid_roa(const char *, struct cert *, struct roa *);
-int valid_filehash(int, const char *, size_t);
+int valid_filehash(int, const char *, const char *,
+ const unsigned char *, size_t);
int valid_hash(unsigned char *, size_t, const char *, size_t);
int valid_filename(const char *, size_t);
int valid_uri(const char *, size_t, const char *);
Index: parser.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/parser.c,v
retrieving revision 1.93
diff -u -p -r1.93 parser.c
--- parser.c27 Apr 2023 08:37:53 - 1.93
+++ parser.c10 May 2023 17:34:57 -
@@ -177,20 +177,21 @@ proc_parser_mft_check(const char *fn, st
fd = open(path, O_RDONLY);
if (fd == -1 && errno == ENOENT)
noent++;
- free(path);
/* remember which path was checked */
m->location = loc[try];
- valid = valid_filehash(fd, m->hash, sizeof(m->hash));
+
+ valid = valid_filehash(fd, path, m->file, m->hash,
+ sizeof(m->hash));
+ free(path);
}
if (!valid) {
/* silently skip not-existing unknown files */
if (m->type == RTYPE_INVALID && noent == 2)
continue;
- warnx("%s: bad message digest for %s", fn, m->file);
+ warnx("%s#%s: missing %s", fn, p->seqnum, m->file);
rc = 0;
- continue;
}
}
Index: repo.c
===
RCS file: /cvs/src/usr.sbin/rpki-client/repo.c,v
retrieving revision 1.44
diff -u -p -r1.44 repo.c
--- repo.c 26 Apr 2023 16:32:41 - 1.44
+++ repo.c 10 May 2023 17:34:57 -
@@ -827,8 +827,7 @@ rrdp_handle_file(unsigned int id, enum p
fd
openrsync: Fix a file descriptor leak
Index: main.c === RCS file: /cvs/src/usr.bin/rsync/main.c,v retrieving revision 1.68 diff -u -p -r1.68 main.c --- main.c 28 Apr 2023 10:24:38 - 1.68 +++ main.c 10 May 2023 17:43:23 - @@ -602,6 +602,7 @@ basedir: err(ERR_IPC, "dup2"); if (dup2(fds[1], STDOUT_FILENO) == -1) err(ERR_IPC, "dup2"); + close(fds[1]); execvp(args[0], args); _exit(ERR_IPC); /* NOTREACHED */
sigsuspend.2: document behavior for discarded signals
The sigsuspend(2) man page doesn't spell out explicitly what happens for signals that are discarded, either as the default action or where the handler is set to SIG_IGN. I think it should. OK? - todd Index: lib/libc/sys/sigsuspend.2 === RCS file: /cvs/src/lib/libc/sys/sigsuspend.2,v retrieving revision 1.14 diff -u -p -u -r1.14 sigsuspend.2 --- lib/libc/sys/sigsuspend.2 29 May 2017 09:40:02 - 1.14 +++ lib/libc/sys/sigsuspend.2 10 May 2023 17:25:44 - @@ -44,12 +44,15 @@ .Fn sigsuspend temporarily changes the blocked signal mask to the set to which .Fa sigmask -points, -and then waits for a signal to arrive; -on return the previous set of masked signals is restored. -The signal mask set -is usually empty to indicate that all +points, then waits for a signal to arrive that either has a handler +installed or that terminates the process. +On return, the previous set of masked signals is restored. +The signal mask set is usually empty to indicate that all signals are to be unblocked for the duration of the call. +Signals that are discarded by default, or that have the handler set to +.Dv SIG_IGN , +will not interrupt +.Nm . .Pp In normal usage, a signal is blocked using .Xr sigprocmask 2
Re: seperate LRO/TSO flags
On Wed, 10 May 2023 19:03:58 +0200, Jan Klemkow wrote: > This diff introduces separate flags for TCP offloading. We split this > into LRO (large receive offloading) and TSO (TCP segmentation > offloading). Thus, we are able to turn it on/off separately. > > For ifconfig(8) we use "tcprecvoffload" and "tcpsendoffload". So, the > user has a better insight of what this features are doing. Is it possible to control these at the address family level? In other words, is it possible to enable "tcprecvoffload" and "tcpsendoffload" for inet but not inet6 or vice versa? - todd
seperate LRO/TSO flags
Hi,
This diff introduces separate flags for TCP offloading. We split this
into LRO (large receive offloading) and TSO (TCP segmentation
offloading). Thus, we are able to turn it on/off separately.
For ifconfig(8) we use "tcprecvoffload" and "tcpsendoffload". So, the
user has a better insight of what this features are doing.
ok?
bye,
Jan
Index: sbin/ifconfig/ifconfig.8
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.394
diff -u -p -r1.394 ifconfig.8
--- sbin/ifconfig/ifconfig.826 Apr 2023 02:38:08 - 1.394
+++ sbin/ifconfig/ifconfig.810 May 2023 16:22:30 -
@@ -282,8 +282,10 @@ tag.
As CSUM_TCPv4, but supports IPv6 datagrams.
.It Sy CSUM_UDPv6
As above, for UDP.
+.It Sy LRO
+The device supports TCP large receive offloading (LRO).
.It Sy TSO
-The device supports TCP segment offloading (TSO).
+The device supports TCP segmentation offloading (TSO).
.It Sy WOL
The device supports Wake on LAN (WoL).
.It Sy hardmtu
@@ -491,10 +493,30 @@ Query and display information and diagno
modules installed in an interface.
It is only supported by drivers implementing the necessary functionality
on hardware which supports it.
-.It Cm tso
+.It Cm tcprecvoffload
+Enable TCP large receive offloading (LRO) if it's supported by the hardware;
see
+.Cm hwfeatures .
+LRO enabled network interfaces modify received TCP/IP packets.
+This will also affect traffic of upper layer interfaces,
+such as
+.Xr vlan 4 ,
+.Xr aggr 4 ,
+and
+.Xr carp 4 .
+It is not possible to use LRO with interfaces attached to a
+.Xr bridge 4 ,
+.Xr veb 4 ,
+or
+.Xr tpmr 4 .
+Changing this option will re-initialize the network interface.
+.It Cm -tcprecvoffload
+Disable LRO.
+LRO is disabled by default.
+.It Cm tcpsendoffload
Enable TCP segmentation offloading (TSO) if it's supported by the hardware; see
.Cm hwfeatures .
-TSO enabled NICs modify received TCP/IP packets.
+TSO enabled network interfaces are able to split large TCP segments into
smaller
+peaces that fits into MTU and MSS.
This will also affect traffic of upper layer interfaces,
such as
.Xr vlan 4 ,
@@ -506,8 +528,7 @@ It is not possible to use TSO with inter
.Xr veb 4 ,
or
.Xr tpmr 4 .
-Changing this option will re-initialize the network interface.
-.It Cm -tso
+.It Cm -tcpsendoffload
Disable TSO.
TSO is disabled by default.
.It Cm up
Index: sbin/ifconfig/ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.462
diff -u -p -r1.462 ifconfig.c
--- sbin/ifconfig/ifconfig.c8 Mar 2023 04:43:06 - 1.462
+++ sbin/ifconfig/ifconfig.c10 May 2023 15:40:17 -
@@ -126,7 +126,7 @@
#define HWFEATURESBITS \
"\024\1CSUM_IPv4\2CSUM_TCPv4\3CSUM_UDPv4" \
"\5VLAN_MTU\6VLAN_HWTAGGING\10CSUM_TCPv6" \
- "\11CSUM_UDPv6\17TSO\20WOL"
+ "\11CSUM_UDPv6\16LRO\17TSO\20WOL"
struct ifencap {
unsigned int ife_flags;
@@ -469,8 +469,10 @@ const struct cmd {
{ "-soii", IFXF_INET6_NOSOII, 0, setifxflags },
{ "monitor",IFXF_MONITOR, 0, setifxflags },
{ "-monitor", -IFXF_MONITOR, 0, setifxflags },
- { "tso",IFXF_TSO, 0, setifxflags },
- { "-tso", -IFXF_TSO, 0, setifxflags },
+ { "tcprecvoffload", IFXF_LRO, 0, setifxflags },
+ { "-tcprecvoffload", -IFXF_LRO, 0, setifxflags },
+ { "tcpsendoffload", IFXF_TSO, 0, setifxflags },
+ { "-tcpsendoffload", -IFXF_TSO, 0, setifxflags },
#ifndef SMALL
{ "hwfeatures", NEXTARG0, 0, printifhwfeatures },
{ "metric", NEXTARG,0, setifmetric },
@@ -674,7 +676,7 @@ const structcmd {
"\7RUNNING\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX"\
"\15LINK0\16LINK1\17LINK2\20MULTICAST" \
"\23AUTOCONF6TEMP\24MPLS\25WOL\26AUTOCONF6\27INET6_NOSOII" \
- "\30AUTOCONF4" "\31MONITOR" "\32TSO"
+ "\30AUTOCONF4" "\31MONITOR" "\32LRO" "\33TSO"
intgetinfo(struct ifreq *, int);
void getsock(int);
Index: sys/dev/pci/if_ix.c
===
RCS file: /cvs/src/sys/dev/pci/if_ix.c,v
retrieving revision 1.193
diff -u -p -r1.193 if_ix.c
--- sys/dev/pci/if_ix.c 28 Apr 2023 10:18:57 - 1.193
+++ sys/dev/pci/if_ix.c 10 May 2023 16:32:44 -
@@ -1925,7 +1925,7 @@ ixgbe_setup_interface(struct ix_softc *s
ifp->if_capabilities |= IFCAP_CSUM_IPv4;
if (sc->hw.mac.type != ixgbe_mac_82598EB)
- ifp->if_capabilities |= IFCAP_TSO;
+ ifp->if_capabilities |= IFCAP_LRO;
/*
*
Re: smtpd: nits to reduce the diff with -portable
On Wed, 10 May 2023 09:25:43 +0200, Omar Polo wrote: > I forgot to include one off_t cast since it was in a different > directory and -even if off topic because it's not in portable- instead > of "const"-ify only tz why don't mark as const also the two arrays day > and month? Sure. OK millert@ for this one too. - todd
Re: software tcp send offloading
On 9.5.2023. 9:56, Alexander Bluhm wrote: > On Sun, May 07, 2023 at 09:00:31PM +0200, Alexander Bluhm wrote: >> Not sure if I addressed all corner cases already. I think IPsec >> is missing. > Updated diff: > - parts have been commited > - works with IPsec now > - some bugs fixed > - sysctl net.inet.tcp.tso > - netstat TSO counter > > If you test this, recompile sysctl and netstat with new kernel > headers. Then you can see, whether the diff has an effect on your > setup. > > # netstat -s -p tcp | grep TSO > 79 output TSO packets software chopped > 0 output TSO packets hardware processed > 840 output TSO packets generated > 0 output TSO packets dropped > > If you run into problems, disable the feature, and report if the > problem goes away. This helps to locate the bug. > > # sysctl net.inet.tcp.tso=0 > net.inet.tcp.tso: 1 -> 0 > > I would like to keep the sysctl for now. It makes performance > comparison easier. When we add hardware TSO it can be a quick > workaround for driver problems. > > When this has been tested a bit, I think it is ready for commit. > Remaining issues can be handled in tree. My tests pass, I am not > aware of TCP problems. Hi, I've tested this with few iperf3/tcpbench clients. While generating traffic disabling and enabling net.inet.tcp.tso and the difference in performance compared to hw TSO is small, but visible ... netstat -s -p tcp | grep TSO 61559792 output TSO packets software chopped 0 output TSO packets hardware processed 685352918 output TSO packets generated 0 output TSO packets dropped PID TID PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 79516 543359 5900K 1384K onproc/0 -11:35 42.68% softnet 50096 165854 100 5432K 7400K sleep/1 netlock 7:16 38.92% iperf3 60190 204914 100 5440K 7316K sleep/2 netlock 7:03 37.89% iperf3 72560 588715 100 5428K 7408K sleep/3 netlock 7:17 37.16% iperf3 30689 450329 100 5436K 7424K sleep/1 netlock 7:16 37.06% iperf3 66203 324544 100 5440K 7352K sleep/3 netlock 4:30 29.83% iperf3 88977 447186 100 5432K 7376K sleep/5 netlock 4:34 29.74% iperf3 6101 488471 100 5444K 7412K sleep/5 netlock 4:34 28.76% iperf3 2186 575957 100 5436K 7376K sleep/2 netlock 4:32 28.12% iperf3 77920 442144 1000K 1384K sleep/1 bored 7:00 22.27% softnet 48409 243224 1400K 1384K sleep/2 netlock 6:29 21.14% softnet 91863 516055 1000K 1384K sleep/4 bored 6:09 21.09% softnet 67265 156637 -2200K 1384K run/0 - 0:17 0.10% softclock
Re: malloc: less unlock/lock dancing
On Wed, May 10, 2023 at 10:08:09AM +0200, Theo Buehler wrote: > > Thanks! It has been committed. I doubt though if the Go runtime uses > > libc malloc. > > I don't know if the pure Go runtime uses libc malloc. However, some > of the test code involves cgo and calls into various C libraries > including libcrypto. So it definitely exercised malloc in a threaded > environment. Good to know, thanks again, -Otto
Re: malloc: less unlock/lock dancing
> Thanks! It has been committed. I doubt though if the Go runtime uses > libc malloc. I don't know if the pure Go runtime uses libc malloc. However, some of the test code involves cgo and calls into various C libraries including libcrypto. So it definitely exercised malloc in a threaded environment.
Re: malloc: less unlock/lock dancing
On Tue, May 09, 2023 at 09:55:32PM +0200, Theo Buehler wrote: > On Thu, May 04, 2023 at 03:40:35PM +0200, Otto Moerbeek wrote: > > On Thu, Apr 27, 2023 at 02:17:10PM +0200, Otto Moerbeek wrote: > > > > > This was introduced to not stall other threads while mmap is called by > > > a thread. But now that mmap is unlocked, I believe it is no longer > > > useful. > > > > > > A full build is slighlty faster with this. But this also needs testing > > > with you favorite multithreaded program. > > > > I'd really would like some feedback/performance tests on this. > > I see the same: slight reduction of 'make build' time and it also works > fine with heavily threaded things like some Go that I play with. I have > put this through a full bulk build with no fallout. It seems to be > slightly faster for this as well. > > I have been running this on several machines including my main laptop > and could not spot a single downside. > > The diff makes sense, so > > ok tb Thanks! It has been committed. I doubt though if the Go runtime uses libc malloc. -Otto
Re: smtpd: nits to reduce the diff with -portable
On 2023/05/10 09:30:12 +0200, Theo Buehler wrote: > > I forgot to include one off_t cast since it was in a different > > directory and -even if off topic because it's not in portable- instead > > of "const"-ify only tz why don't mark as const also the two arrays day > > and month? > > ok. > > The previous diff used (long long int) and this one now uses (long long). > Would be nice to be consistent. Yes, indeed. smtpd uses `long long int', while for mail.local doesn't have any. I'll go with `long long int' for consistency, typed `long long' out of muscular memory. thanks!
Re: smtpd: nits to reduce the diff with -portable
On Wed, May 10, 2023 at 09:25:43AM +0200, Omar Polo wrote: > On 2023/05/09 19:41:51 -0600, "Todd C. Miller" wrote: > > On Wed, 10 May 2023 00:55:54 +0200, Omar Polo wrote: > > > > > As per subject, here's a few misc nits that would reduce the > > > difference with -portable. There's some printing of time_t via > > > casting to long long, some missing includes (even if in tree it builds > > > nevertheless) and a const for a variable (no idea how it went there in > > > -portable but it's not wrong so including that too.) > > > > OK millert@ > > thanks! > > I forgot to include one off_t cast since it was in a different > directory and -even if off topic because it's not in portable- instead > of "const"-ify only tz why don't mark as const also the two arrays day > and month? ok. The previous diff used (long long int) and this one now uses (long long). Would be nice to be consistent.
Re: smtpd: nits to reduce the diff with -portable
On 2023/05/09 19:41:51 -0600, "Todd C. Miller" wrote:
> On Wed, 10 May 2023 00:55:54 +0200, Omar Polo wrote:
>
> > As per subject, here's a few misc nits that would reduce the
> > difference with -portable. There's some printing of time_t via
> > casting to long long, some missing includes (even if in tree it builds
> > nevertheless) and a const for a variable (no idea how it went there in
> > -portable but it's not wrong so including that too.)
>
> OK millert@
thanks!
I forgot to include one off_t cast since it was in a different
directory and -even if off topic because it's not in portable- instead
of "const"-ify only tz why don't mark as const also the two arrays day
and month?
sorry for forgetting these in the previous mail,
diff /usr/src
commit - a2d3cb1e480c37eb6fb14cee9f2946606a0346bc
path + /usr/src
blob - a0d38b1a7c0c7f7016b7d3f69e1c5dad77227e2a
file + libexec/mail.local/mail.local.c
--- libexec/mail.local/mail.local.c
+++ libexec/mail.local/mail.local.c
@@ -243,7 +243,8 @@ retry:
}
curoff = lseek(mbfd, 0, SEEK_END);
- (void)snprintf(biffmsg, sizeof biffmsg, "%s@%lld\n", name, curoff);
+ (void)snprintf(biffmsg, sizeof biffmsg, "%s@%lld\n", name,
+ (long long)curoff);
if (lseek(fd, 0, SEEK_SET) == (off_t)-1) {
mwarn("temporary file: %s", strerror(errno));
goto bad;
blob - 6e340ccde1a521ff13805c6f31d38ee77eb5ad50
file + usr.sbin/smtpd/to.c
--- usr.sbin/smtpd/to.c
+++ usr.sbin/smtpd/to.c
@@ -140,10 +140,10 @@ time_to_text(time_t when)
{
struct tm *lt;
static char buf[40];
- char *day[] = {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"};
- char *month[] = {"Jan","Feb","Mar","Apr","May","Jun",
+ const char *day[] = {"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"};
+ const char *month[] = {"Jan","Feb","Mar","Apr","May","Jun",
"Jul","Aug","Sep","Oct","Nov","Dec"};
- char *tz;
+ const char *tz;
long offset;
lt = localtime();
