Re: wg(4): encapsulated transport checksums

2020-06-30 Thread Claudio Jeker
On Tue, Jun 30, 2020 at 09:22:18AM +1200, richard.n.proc...@gmail.com wrote: > Hi Jason, > > On 27/06/2020, at 10:09 PM, Jason A. Donenfeld wrote: > > [...] I thought I'd lay out my understanding of the matter, > > and you can let me know whether or not this corresponds with what you > > had

Re: if_delgroup(): Add size to free(9) call

2020-06-30 Thread Vitaliy Makkoveev
On Tue, Jun 30, 2020 at 04:11:59AM +0200, Klemens Nanni wrote: > Interface groups are allocated as follows: > > struct ifg_group * > if_creategroup(const char *groupname) > { > struct ifg_group*ifg; > > if ((ifg = malloc(sizeof(*ifg), M_TEMP,

Re: fix races in if_clone_create()

2020-06-30 Thread Martin Pieuchot
On 29/06/20(Mon) 11:59, Vitaliy Makkoveev wrote: > [...] > I reworked tool for reproduce. Now I avoided fork()/exec() route and it > takes couple of minutes to take panic on 4 cores. Also some screenshots > attached. Setting kern.pool_debug=2 makes the race reproducible in seconds. Could you

[PATCH] usr.sbin/rpki-client: remove -f (force) option

2020-06-30 Thread Job Snijders
Remove rpki-client's -f command line option I haven't come across a use case that requires tricking the software into accepting out-of-date manifests. Anyone using -f? I think this is a leftover from the initial debugging era. OK? Index: extern.h

Re: [PATCH] usr.sbin/rpki-client: remove -f (force) option

2020-06-30 Thread Klemens Nanni
OK kn with the manual's synopsis (`man -h rpki-client') updated as well.

Re: [PATCH] usr.sbin/rpki-client: remove -f (force) option

2020-06-30 Thread Claudio Jeker
On Tue, Jun 30, 2020 at 10:33:21AM +, Job Snijders wrote: > Remove rpki-client's -f command line option > > I haven't come across a use case that requires tricking the software > into accepting out-of-date manifests. Anyone using -f? I think this is a > leftover from the initial debugging

Re: pipex(4): kill unused declaration

2020-06-30 Thread Claudio Jeker
On Tue, Jun 30, 2020 at 04:30:24PM +0300, Vitaliy Makkoveev wrote: > `udpcksum' declared but not used in net/pipex.c, so kill it OK claudio@ > Index: sys/net/pipex.c > === > RCS file: /cvs/src/sys/net/pipex.c,v > retrieving revision

pipex(4): kill unused declaration

2020-06-30 Thread Vitaliy Makkoveev
`udpcksum' declared but not used in net/pipex.c, so kill it Index: sys/net/pipex.c === RCS file: /cvs/src/sys/net/pipex.c,v retrieving revision 1.116 diff -u -p -r1.116 pipex.c --- sys/net/pipex.c 22 Jun 2020 09:38:15 -

Re: fix races in if_clone_create()

2020-06-30 Thread Vitaliy Makkoveev
On Tue, Jun 30, 2020 at 12:08:03PM +0200, Martin Pieuchot wrote: > On 29/06/20(Mon) 11:59, Vitaliy Makkoveev wrote: > > [...] > > I reworked tool for reproduce. Now I avoided fork()/exec() route and it > > takes couple of minutes to take panic on 4 cores. Also some screenshots > > attached. > >

sparc64: vdsk: add size to free(9) call

2020-06-30 Thread Klemens Nanni
Without any later realloactions, size is taken from vdsk_dring_alloc(): struct vdisk_dring *vd; ... vd = malloc(sizeof(struct vdsk_dring), M_DEVBUF, M_NOWAIT); Tested on T4-2 guest domains, altough that of course just means that allocating rings keeps working as before

Re: fix races in if_clone_create()

2020-06-30 Thread Vitaliy Makkoveev
On Tue, Jun 30, 2020 at 03:48:22PM +0300, Vitaliy Makkoveev wrote: > On Tue, Jun 30, 2020 at 12:08:03PM +0200, Martin Pieuchot wrote: > > On 29/06/20(Mon) 11:59, Vitaliy Makkoveev wrote: > > > [...] > > > I reworked tool for reproduce. Now I avoided fork()/exec() route and it > > > takes couple

sparc64: vnet: add size to free(9) call

2020-06-30 Thread Klemens Nanni
Without any later realloactions, size is taken from vnet_dring_alloc(): struct vnet_dring *vd; ... vd = malloc(sizeof(struct vnet_dring), M_DEVBUF, M_NOWAIT); Tested on T4-2 guest domains: vnet0 at cbus0 chan 0x6: ivec 0xc, 0xd, address 00:14:4f:f9:3f:34

Re: wg(4): encapsulated transport checksums

2020-06-30 Thread Matt Dunwoodie
On Tue, 30 Jun 2020 09:22:18 +1200 (NZST) richard.n.proc...@gmail.com wrote: > Hi Jason, > > On 27/06/2020, at 10:09 PM, Jason A. Donenfeld > wrote: > > [...] I thought I'd lay out my understanding of the matter, > > and you can let me know whether or not this corresponds with what > > you had

Re: wg(4): encapsulated transport checksums

2020-06-30 Thread Matt Dunwoodie
On Tue, 30 Jun 2020 20:40:10 -0600 "Theo de Raadt" wrote: > Matt Dunwoodie wrote: > > > Depends on your definition of significant, I've seen 1-3% throughput > > improvement without the patch. > > > Real networks require statistics, which you want to throw away. > > > Overall, it is still

Re: wg(4): encapsulated transport checksums

2020-06-30 Thread Theo de Raadt
Matt Dunwoodie wrote: > Depends on your definition of significant, I've seen 1-3% throughput > improvement without the patch. > Real networks require statistics, which you want to throw away. > Overall, it is still debatable whether to skip the IPv4 checksum as > modern crypto certainly offers