Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Jason A. Donenfeld
Hi Otto, On Wed, May 27, 2020 at 4:07 AM Otto Moerbeek wrote: > Although I'm not terribly interested in bugs that are only seen (s0 > far) using emulation, please send me the details on how you set up > qemu. Right, it could very well be a TCG bug. But maybe not. Here's how to get things

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Matt Dunwoodie
On Wed, 27 May 2020 01:43:34 -0600 "Jason A. Donenfeld" wrote: > On Wed, May 27, 2020 at 1:34 AM Martin Pieuchot > wrote: > > First question is, is it possible to use the wg(4) interface > > without a port? > > No, that is not how WireGuard works. For details on the actual > protocol

pipex(4): kill NET_LOCK() in pipex_ioctl()

2020-05-27 Thread Vitaliy Makkoveev
pipex(4) is simultaneously protected by KERNEL_LOCK() and NET_LOCK() and the last is not required. I guess to start remove NET_LOCK(). Diff below drops NET_LOCK() in pipex_ioctl() and underlaying routines. At least this helps to kill unlock/lock mess in pppx_add_session() and pppx_if_destroy().

Re: clear margins when remapping efifb

2020-05-27 Thread Mark Kettenis
> Date: Wed, 27 May 2020 19:39:07 +1000 > From: Jonathan Gray > > When testing the row and column increase for efifb on a 1920x1080 > display I noticed the top part of the screen continues to contain part > of a white on blue line from earlier in the dmesg even after the machine > has finished

Remove KERNEL_LOCK() in socket(2) and socketpair(2)

2020-05-27 Thread Martin Pieuchot
When these two syscalls have been marked NOLOCK, falloc(), fdinsert() & friends weren't ready to be executed without KERNEL_LOCK(). This is no longer true. kqueue(2), for example, do the same dances without this lock. ok? Index: kern/uipc_syscalls.c

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Matt Dunwoodie
On Wed, 27 May 2020 09:34:53 +0200 Martin Pieuchot wrote: > Hello Matt, > > Thank you for your submission. Hi Martin, No worries, thank you for your feedback. This is something I want to help make happen and if I recall correctly, someone once said that if I wanted a new feature on OpenBSD

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Otto Moerbeek
On Wed, May 27, 2020 at 03:14:29AM -0600, Jason A. Donenfeld wrote: > One interesting quirk in doing this on qemu is that the 6.7 and > -current kernel both crash: > > Loading FCode image... > Loaded 6882 bytes > entry point is 0x4000 > Evaluating FCode... > OpenBSD IEEE 1275 Bootblock 2.0 >

clear margins when remapping efifb

2020-05-27 Thread Jonathan Gray
When testing the row and column increase for efifb on a 1920x1080 display I noticed the top part of the screen continues to contain part of a white on blue line from earlier in the dmesg even after the machine has finished booting. RI_CENTER changes the ri_bits offset, doing RI_CLEARMARGINS in

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Jason A. Donenfeld
On Wed, May 27, 2020 at 2:12 AM Jason A. Donenfeld wrote: > > Hi again Klemens, > > On Tue, May 26, 2020 at 5:42 PM Jason A. Donenfeld wrote: > > > > On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote: > > > With regards to your crash, though, that's a bit more puzzling, and > > > I'd be

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Jason A. Donenfeld
Hey David, On Wed, May 27, 2020 at 2:26 AM David Gwynne wrote: > > On Tue, May 26, 2020 at 05:42:13PM -0600, Jason A. Donenfeld wrote: > > On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote: > > > With regards to your crash, though, that's a bit more puzzling, and > > > I'd be interested

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread David Gwynne
On Tue, May 26, 2020 at 05:42:13PM -0600, Jason A. Donenfeld wrote: > On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote: > > With regards to your crash, though, that's a bit more puzzling, and > > I'd be interested to learn more details. Because these structs are > > already naturally

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Jason A. Donenfeld
Hi again Klemens, On Tue, May 26, 2020 at 5:42 PM Jason A. Donenfeld wrote: > > On Tue, May 26, 2020 at 4:52 PM Jason A. Donenfeld wrote: > > With regards to your crash, though, that's a bit more puzzling, and > > I'd be interested to learn more details. Because these structs are > > already

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Matt Dunwoodie
On Tue, 26 May 2020 13:28:22 +0200 Tobias Heider wrote: > Hi Matt, > > just repeating what I commented yesterday for the new diff to make > sure it isn't overlooked. Thank you for repeating it, I didn't get around to addressing it before the new diff. > > +int > > +wg_ioctl_get(struct

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Jason A. Donenfeld
Hi Martin, To answer a few but not all of your questions: On Wed, May 27, 2020 at 1:34 AM Martin Pieuchot wrote: > First question is, is it possible to use the wg(4) interface without a > port? No, that is not how WireGuard works. For details on the actual protocol particulars, please see

Re: WireGuard patchset for OpenBSD, rev. 2

2020-05-27 Thread Martin Pieuchot
Hello Matt, Thank you for your submission. On 26/05/20(Tue) 19:39, Matt Dunwoodie wrote: > After some feedback and comments, we've addressed the concerns, and > fixed a few things from our side too. Overall the structure is familiar > with no major changes, so any prior readings mostly carry

Re: [RFC] pppd: add pipex(4) L2TP control support

2020-05-27 Thread Martin Pieuchot
On 26/05/20(Tue) 10:31, Claudio Jeker wrote: > [...] > npppd(8) is server only it can not establish a connection. pppd(8) on the > other hand is more client side (but I think it can do both). Could someone knowledgable indicate that in the man pages? Currently there is: npppd – new