fortune: typo: than -> then

Index: games/fortune/datfiles/fortunes2 === RCS file: /cvs/src/games/fortune/datfiles/fortunes2,v retrieving revision 1.48 diff -u -p -r1.48 fortunes2 --- games/fortune/datfiles/fortunes213 Jul 2017 02:45:56 - 1.48 +++

[PATCH 1/2] VMD: vioscsi support for cdrom

Add -r to vmctl start to specify cdrom iso Add 'cdrom' keyword to vm section in vm.conf Updated manpages for vmctl(8) and vm.conf(5) handling opcodes: - TEST_UNIT_READY - INQUIRY - PREVENT_ALLOW - READ_CAPACITY - READ_CAPACITY_16 - READ_TOC - READ_COMMAND - READ_BIG - START_STOP diff --git

[PATCH 0/2] Add initial support for cdrom using vioscsi

This patchset adds the initial support for a vioscsi cdrom. Tests were done using: * large ( > 4GB) and small isos * OpenBSD as the guest (primary testing) * Seabios as the kernel (primary testing) It is expected that there's a possibility of adding more opcodes as the set of testing VMs

[PATCH 2/2] VMD: add regress tests for cdrom keyword

Add regress tests for cdrom keyword diff --git regress/usr.sbin/vmd/config/Makefile regress/usr.sbin/vmd/config/Makefile index 2adc69ae491..91e19037b9c 100644 --- regress/usr.sbin/vmd/config/Makefile +++ regress/usr.sbin/vmd/config/Makefile @@ -2,10 +2,10 @@ VMD ?= /usr/sbin/vmd

FUSE: rename doesn't unlock target vnode

When renaming a file on a FUSE file system and the target exists and is open, a deadlock will occur because the target vnode (tvp) has not been unlocked by fusefs_rename(). When the process that has the file open calls close(2) the vnode will still be locked with no chance of ever being unlocked.

VOP_LOOKUP(9) man page VOP_RENAME(9) errata

The VOP_LOOKUP(9) man page incorrectly states the following about VOP_RENAME(9). "If not NULL, tvp will be locked on return as well." However, dorenameat() in /sys/kern/vfs_syscalls.c unlocks tvp on error and file systems unlock it on success. This patch changes this line to read "unlocked".

isakmpd: use monotonic clock for event timeouts

Hi, These events are meants to fire after an interval has elapsed, so we should use the monotonic clock to measure. The pattern throughout the daemon of loading the current time, adding a timeout to the structure member, and then passing a pointer to said structure to timer_add_event() seemed

Re: Intel HSUART/8250 LPSS

On Fri, 24 Nov 2017 20:26:02 +0100 (CET) > This device is based on the same Synopsys Designware "IP" as what's > found on many ARM SoCs. Pretty much com(4) compatible but with some > twists. > > 1. The registers are wider. Instead of the traditional 1-byte >registers it has 4-byte

Re: Intel HSUART/8250 LPSS

> Date: Fri, 24 Nov 2017 19:01:21 + > From: Kevin Chadwick > > I am looking into getting Intel HSUART/8250 LPSS support working. Has > anyone done any work on this out of tree. Or is there anything I should > be aware of. This device is based on the same Synopsys

Re: pfctl fails to handle nested 'load anchor' properly

On Fri, Nov 24, 2017 at 02:58:48PM +0100, Alexandr Nedvedicky wrote: > this diff is part of the 'big patch' [1] to pfctl I've sent while back. The > pfctl fails to handle nested 'load anchor' statements properly, when ruleset > is > being loaded to non-root anchor (e.g. pfctl -a regress ...),

Intel HSUART/8250 LPSS

I am looking into getting Intel HSUART/8250 LPSS support working. Has anyone done any work on this out of tree. Or is there anything I should be aware of. Thanks

Re: pfctl rule optimizer: anchor name vs. anchor path mix up

On Fri, Nov 24, 2017 at 11:36:28AM +0100, Alexandr Nedvedicky wrote: > this is yet another occurrence of infamous 'name vs. path mix up' [1]. > Leonardo Guardati hit this bug in rule optimizer this time. The patch > below is part of 'the big diff' I've sent while ago [2]. > > OK? OK bluhm@ >

Re: patching use-after-free and innocent memory leak in pfctl_optimzie.c

On Fri, Nov 24, 2017 at 01:11:08PM +0100, Alexandr Nedvedicky wrote: > the patch below is part of larger diff [1] I've sent earlier. Leonardo seen a > pfctl.core, when pfctl_optimize failed to create a radix table. The use after > free happens in superblock_free() at 1621: I have seen exactly

pfctl fails to handle nested 'load anchor' properly

Hello, this diff is part of the 'big patch' [1] to pfctl I've sent while back. The pfctl fails to handle nested 'load anchor' statements properly, when ruleset is being loaded to non-root anchor (e.g. pfctl -a regress ...), see [1] to find more details about the issue. The first step towards

Re: openssl s_time, speed: use monotime for absolute interval measurement

> On Nov 24, 2017, at 6:58 AM, Jeremie Courreges-Anglas wrote: > > On Wed, Nov 22 2017, Scott Cheloha wrote: >> Whoops, ignore that last patch, it lacked the >> static changes in apps_posix.c > > This looks good to me. I'm tempted to commit the

Re: openssl s_time, speed: use monotime for absolute interval measurement

On Wed, Nov 22 2017, Scott Cheloha wrote: > Whoops, ignore that last patch, it lacked the > static changes in apps_posix.c This looks good to me. I'm tempted to commit the apps_posix.c part first: it seems to me that app_tminterval() could be reused in s_time.c, leading

patching use-after-free and innocent memory leak in pfctl_optimzie.c

Hello, the patch below is part of larger diff [1] I've sent earlier. Leonardo seen a pfctl.core, when pfctl_optimize failed to create a radix table. The use after free happens in superblock_free() at 1621: 1618 while ((por = TAILQ_FIRST(>sb_rules))) { 1619

pfctl rule optimizer: anchor name vs. anchor path mix up

Hello, this is yet another occurrence of infamous 'name vs. path mix up' [1]. Leonardo Guardati hit this bug in rule optimizer this time. The patch below is part of 'the big diff' I've sent while ago [2]. OK? thanks and regard sasha [1] https://marc.info/?l=openbsd-tech=147289981326044=2 [2]