On Mon, May 01, 2017 at 01:36:51PM +0100, Nicholas Marriott wrote:
>
> looks good, ok nicm
Anyone willing to commit?
> On Mon, May 01, 2017 at 10:35:59AM +0200, Tobias Stoeckmann wrote:
> > Hi,
> >
> > On Mon, May 01, 2017 at 09:15:45AM +0200, Anton Lindqvist wrote:
> > > While freeing tag entr
Errata patches for dhcpd, vmm, LibreSSL and softraid have been released
for OpenBSD 6.1 today.
Details can be found on this page: https://www.openbsd.org/errata61.html
Binary updates for the amd64 and i386 platforms are also available via
the syspatch utility. Note that syspatch uses the mirror c
> Joe Holden wrote:
> > Hi guys,
> >
> > Below is a revised patch (should be unmangled this time) that adds an -f
> > option to print the first unused vnd_dev, fixed style nits and unbroken
> > getopt. hat tip to Theo Buehler for pointers:
>
> I don't like that this creates an inherent race condi
Joe Holden wrote:
> Hi guys,
>
> Below is a revised patch (should be unmangled this time) that adds an -f
> option to print the first unused vnd_dev, fixed style nits and unbroken
> getopt. hat tip to Theo Buehler for pointers:
I don't like that this creates an inherent race condition. That's gua
Hi guys,
Below is a revised patch (should be unmangled this time) that adds an -f
option to print the first unused vnd_dev, fixed style nits and unbroken
getopt. hat tip to Theo Buehler for pointers:
Index: sbin/mount_vnd/mount_vnd.8
===
Make it similar to the amd64 and i386 versions.
ok?
Index: arch/arm64/arm64/machdep.c
===
RCS file: /cvs/src/sys/arch/arm64/arm64/machdep.c,v
retrieving revision 1.16
diff -u -p -r1.16 machdep.c
--- arch/arm64/arm64/machdep.c 2 May
On 01.05.2017 12:28, Mark Kettenis wrote:
>> From: Dmitry Vyukov
>> Date: Mon, 1 May 2017 10:43:26 +0200
>>
>> On Mon, May 1, 2017 at 8:51 AM, Greg Steuck wrote:
>>> I naively tried to build something with -fsanitize=address using llvm-4.0
>>> port available on OpenBSD 6.1-amd64. I was immediatel
> > diff --git sys/sys/mbuf.h sys/sys/mbuf.h
> > index 202ce8ced8b..7ca1a779fe0 100644
> > --- sys/sys/mbuf.h
> > +++ sys/sys/mbuf.h
> > @@ -127,10 +127,11 @@ structpkthdr {
> > u_int16_tph_flowid; /* pseudo unique flow id */
> > u_int16_tcsum_fla
On Tue, May 02, 2017 at 19:19 +0200, Mike Belopuhov wrote:
> On Tue, May 02, 2017 at 11:14 -0600, Todd C. Miller wrote:
> > On Tue, 02 May 2017 11:12:58 -0600, "Todd C. Miller" wrote:
> >
> > > On Tue, 02 May 2017 18:59:44 +0200, Mike Belopuhov wrote:
> > >
> > > > After switching the ph_timestam
> diff --git sys/sys/mbuf.h sys/sys/mbuf.h
> index 202ce8ced8b..7ca1a779fe0 100644
> --- sys/sys/mbuf.h
> +++ sys/sys/mbuf.h
> @@ -127,10 +127,11 @@ struct pkthdr {
> u_int16_tph_flowid; /* pseudo unique flow id */
> u_int16_tcsum_flags;/* check
On Tue, May 02, 2017 at 11:14 -0600, Todd C. Miller wrote:
> On Tue, 02 May 2017 11:12:58 -0600, "Todd C. Miller" wrote:
>
> > On Tue, 02 May 2017 18:59:44 +0200, Mike Belopuhov wrote:
> >
> > > After switching the ph_timestamp to int64_t, the implementation
> > > can be re-adjusted to use int64_
On Tue, 02 May 2017 11:12:58 -0600, "Todd C. Miller" wrote:
> On Tue, 02 May 2017 18:59:44 +0200, Mike Belopuhov wrote:
>
> > After switching the ph_timestamp to int64_t, the implementation
> > can be re-adjusted to use int64_t timestamps throughout.
> >
> > I think I've got all of the conversio
On Tue, 02 May 2017 18:59:44 +0200, Mike Belopuhov wrote:
> After switching the ph_timestamp to int64_t, the implementation
> can be re-adjusted to use int64_t timestamps throughout.
>
> I think I've got all of the conversion right, but will double-
> check everything before getting this in.
Wou
On Tue, May 02, 2017 at 10:58 -0600, Theo de Raadt wrote:
> Most important reason to me is less mbuf growth
>
> But what units is this timestamp...
>
Right now it's up to the code using it with a preference for a
nanosecond precision, but once we start using it for more than
one thing, we can fix
On Fri, Apr 28, 2017 at 17:36 +0200, Mike Belopuhov wrote:
> This is an implementation of an FQ-CoDel algorithm that relies
> on Pf for configuration and providing flow information via its
> stateful inspection.
>
Thanks for mpi@, visa@ and sthen@ for looking through the code!
After switching th
Most important reason to me is less mbuf growth
But what units is this timestamp...
> As it appears, there's an argument to use a single 64 bit integer
> instead. Whether use a signed or value or not is debatable, but
> here's an argument to go for signed: time_t, timespec and timeval
> are all
On Fri, Apr 28, 2017 at 15:31 +0200, Mike Belopuhov wrote:
> One of the prerequisites for FQ_CoDel is ability to track packet
> enqueue time. To avoid allocating per-packet mbuf tags, I'd prefer
> to include the timestamp directly into the packet header structure.
> This can be later used for othe
On Tue, May 02, 2017 at 01:53:33PM +0200, Mike Belopuhov wrote:
> OK?
ok
On Tue, May 02, 2017 at 01:56:37PM +0200, Mike Belopuhov wrote:
> OK?
ok
On Mon, May 01, 2017 at 06:02:24PM +0200, Mark Kettenis wrote:
> The futex(2) syscall needs to be able to atomically copy the futex in
> and out of userland. The current implementation uses copyin(9) and
> copyout(9) for that. The futex is a 32-bit integer, and currently our
> copyin(9) and copyo
What I did:
(S)hell
#fdisk -iy wd0
#disklabel -E wd0
>a a
/Enter-enter-enter/
#fdisk -iy sd0
#disklabel -E sd0
>a e
/Enter/
>32M (The usb drive is big and only for keys so whatever)
>RAID
bioctl -c C -l /dev/wd0a -k /dev/sd0e softraid0
/made sd1/
# dd if=/dev/zero of=/dev/rsd1c bs=1m count=1
Howev
I believe I saw a mention of 6.1 scheduling or I/O being a work in
progress, so this post is simply informational and if you wish me to run
any tests then I can. Otherwise this is not a problem right now though
it has made the daily internal backup into a weekly one.
I am using an old fanless P2 4
There are no more encrypt-only keys, so swap_key_prepare loses a flag.
OK?
---
sys/uvm/uvm_swap_encrypt.c | 31 ---
sys/uvm/uvm_swap_encrypt.h | 2 +-
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git sys/uvm/uvm_swap_encrypt.c sys/uvm/uvm_swap_encrypt.c
OK?
---
regress/sys/crypto/cmac/Makefile| 2 +-
regress/sys/crypto/cmac/cmac_test.c | 2 +-
regress/sys/crypto/key_wrap/Makefile| 2 +-
regress/sys/crypto/key_wrap/key_wrap_test.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git regress/sys/crypto/c
OK?
---
sys/crypto/cmac.c| 12 ++--
sys/crypto/cmac.h| 2 +-
sys/crypto/key_wrap.c| 10 +-
sys/crypto/key_wrap.h| 2 +-
sys/net80211/ieee80211_crypto.c | 2 +-
sys/net80211/ieee80211_crypto_bip.c | 2
As both of you said, some of these will not benefit much since it happens near
the end, nevertheless it's the safe (and easy) idiom we have for "wipe this
sensitive data out of memory". My main beef is that their current code might
get copied by someone elsewhere to a bad place with undesired effec
26 matches
Mail list logo
