Re: pf af-to route output

On Wed, Nov 23, 2016 at 01:43:59AM +0100, Mike Belopuhov wrote: > On 23 November 2016 at 01:42, Alexander Bluhm wrote: > > On Tue, Nov 22, 2016 at 01:44:09PM +0100, Mike Belopuhov wrote: > >> OK, all I wanted to know was if this is know to work and if it has > >> been

Re: smtpd: more internal cleanups

On Wed, Nov 23, 2016 at 09:14:13AM +0530, Sunil Nimmagadda wrote: > > Eric Faurot writes: > > > Hi. > > > > When using the internal io api, the caller had to explicitely reset an > > io event in some cases (basically when data is buffered outside of an > > io callback context) which could easily

Re: Unnecessary goto in ip_output()

On Tue, Nov 22, 2016 at 04:55:17PM +0100, Martin Pieuchot wrote: > After the last IPSEC-related refactoring this goto no longer make sense. > > ok? Are you shure? I'm not convinced that for an INADDR_BROADCAST destination the code would do the same. I think it is fine but I can't prove it. >

armv7/stand/efiboot: working BOOTAA64.EFI payload

Hi, Patch adds armv8/aarch64 EFI payload image build support. With patrick@'s aarch64-none-elf- toolchain referenced in my last mail on this list, you can build it via... $ MACHINE=armv8 armmake64-aarch64 -f Makefile.arm64 ...where armmake64-aarch64 is a simple env wrapper for the toolchain,

Re: smtpd: more internal cleanups

Eric Faurot writes: > Hi. > > When using the internal io api, the caller had to explicitely reset an > io event in some cases (basically when data is buffered outside of an > io callback context) which could easily be missed. This has been the > cause of some of smtpd bugs in the past (hanging

Re: use DRM_IOCTL_GET_PCIINFO in libdrm

On Tue, Nov 22, 2016 at 09:29:03PM +0100, Mark Kettenis wrote: > > Date: Sat, 19 Nov 2016 19:31:18 +1100 > > From: Jonathan Gray > > > > Support libdrm functions required for Mesa versions >= 13. > > > > On linux this information is pulled out of a psuedo filesystem, here the >

Re: add a new DRM_IOCTL_GET_PCIINFO ioctl

On Tue, Nov 22, 2016 at 09:26:21PM +0100, Mark Kettenis wrote: > > Date: Sat, 19 Nov 2016 19:27:25 +1100 > > From: Jonathan Gray > > > > To pull pci information from the kernel for drm devices we need a common > > drm ioctl. This is a requirement for implementing functions in

Re: pf af-to route output

On 23 November 2016 at 01:42, Alexander Bluhm wrote: > On Tue, Nov 22, 2016 at 01:44:09PM +0100, Mike Belopuhov wrote: >> OK, all I wanted to know was if this is know to work and if it has >> been tested. I'd argue that we don't put the code that doesn't work >> or not

Re: pf af-to route output

On Tue, Nov 22, 2016 at 01:44:09PM +0100, Mike Belopuhov wrote: > OK, all I wanted to know was if this is know to work and if it has > been tested. I'd argue that we don't put the code that doesn't work > or not tested or we don't know what it does :) After looking at all the cases, it will be

Re: vio(4): fixup crash on up/down

On Wed, Nov 23, 2016 at 00:42 +0100, Stefan Fritsch wrote: > On Wednesday, 23 November 2016 00:34:42 CET Mike Belopuhov wrote: > > Yes, after looking closer at virtio code I agree with you. > > However, stop/init is purely OpenBSD specific action. There > > are no provisions or requirements from

Re: vio(4): fixup crash on up/down

On Wednesday, 23 November 2016 00:34:42 CET Mike Belopuhov wrote: > Yes, after looking closer at virtio code I agree with you. > However, stop/init is purely OpenBSD specific action. There > are no provisions or requirements from the hardware really. > Thus we can treat UP/DOWN as purely software

Relocate some of the vio(4) (re)init code into vio_init

This moves code that is supposed to be in init, but is in stop right now. Tested on qemu. OK? diff --git sys/dev/pci/if_vio.c sys/dev/pci/if_vio.c index d8c9798..68e6636 100644 --- sys/dev/pci/if_vio.c +++ sys/dev/pci/if_vio.c @@ -662,14 +662,22 @@ vio_media_status(struct ifnet *ifp, struct

Re: vio(4): fixup crash on up/down

On Wed, Nov 23, 2016 at 00:09 +0100, s...@openbsd.org wrote: > On Tue, 22 Nov 2016, Mike Belopuhov wrote: > > > vmd hackers and users seem to be able to trigger the assertion > > below every time they do down and then up (with a dhclient for > > instance): > > > > panic: kernel diagnostic

Fixup tsleeps in vio(4) and make them interruptable

This fixes up tsleep priorities in vio(4) and makes sleeps interruptable so that ifconfig can be killed with ^C. Tested on qemu with a previous diff that makes vio(4) hang there. OK? diff --git sys/dev/pci/if_vio.c sys/dev/pci/if_vio.c index 97af2a2..d8c9798 100644 --- sys/dev/pci/if_vio.c +++

Re: small indentation and spelling diff

On 2016-11-22, Alexander Bluhm wrote: > On Mon, Nov 21, 2016 at 05:36:21PM -0700, Kyle Milz wrote: >> - * everywhere. It wouldn't surprise me if several stacks accidently >> + * everywhere. It wouldn't surprise me if several stacks accidentally >

Re: vio(4): fixup crash on up/down

On Wed, Nov 23, 2016 at 12:09:57AM +0100, s...@openbsd.org wrote: > On Tue, 22 Nov 2016, Mike Belopuhov wrote: > > > vmd hackers and users seem to be able to trigger the assertion > > below every time they do down and then up (with a dhclient for > > instance): > > > > panic: kernel diagnostic

Re: vio(4): fixup crash on up/down

On Tue, 22 Nov 2016, Mike Belopuhov wrote: > vmd hackers and users seem to be able to trigger the assertion > below every time they do down and then up (with a dhclient for > instance): > > panic: kernel diagnostic assertion "m != NULL" failed: file > "/usr/src/sys/dev/pci/if_vio.c", line

smtpd: more internal cleanups

Hi. When using the internal io api, the caller had to explicitely reset an io event in some cases (basically when data is buffered outside of an io callback context) which could easily be missed. This has been the cause of some of smtpd bugs in the past (hanging sessions). After the recent

Re: reloading pf through ansible easy hook

On 11/22/16 15:36, John Boeske wrote: On Tue, Nov 22, 2016 at 10:46 AM, John Boeske wrote I don't understand this philosophical point - why wouldn't you want the rc.d framework to manage pf, quota, etc. whenever it's natural. With pf, for example, it surely is. One of the reasons I loved

Re: vio(4): fixup crash on up/down

On Tue, Nov 22, 2016 at 09:45:30PM +0100, Mike Belopuhov wrote: > vmd hackers and users seem to be able to trigger the assertion > below every time they do down and then up (with a dhclient for > instance): > > panic: kernel diagnostic assertion "m != NULL" failed: file >

vio(4): fixup crash on up/down

vmd hackers and users seem to be able to trigger the assertion below every time they do down and then up (with a dhclient for instance): panic: kernel diagnostic assertion "m != NULL" failed: file "/usr/src/sys/dev/pci/if_vio.c", line 1008 Starting stack trace... panic() at panic+0x10b

Re: reloading pf through ansible easy hook

On Tue, Nov 22, 2016 at 10:46 AM, John Boeske wrote > On Mon, Nov 21, 2016 at 3:48 PM, Antoine Jacoutet wrote > > On Mon, Nov 21, 2016 at 05:34:35PM -0500, sven falempin wrote: > > > Ansible is already managing pkg and service of openBSD , cool > > > > > > If one want to manage pf with it, and

Re: use DRM_IOCTL_GET_PCIINFO in libdrm

> Date: Sat, 19 Nov 2016 19:31:18 +1100 > From: Jonathan Gray > > Support libdrm functions required for Mesa versions >= 13. > > On linux this information is pulled out of a psuedo filesystem, here the > new DRM_IOCTL_GET_PCIINFO ioctl is used for the same. > > Only primary drm

Re: add a new DRM_IOCTL_GET_PCIINFO ioctl

> Date: Sat, 19 Nov 2016 19:27:25 +1100 > From: Jonathan Gray > > To pull pci information from the kernel for drm devices we need a common > drm ioctl. This is a requirement for implementing functions in libdrm > which are used by Mesa >= 13. > > To not clash with drm headers

Re: reloading pf through ansible easy hook

On Mon, Nov 21, 2016 at 3:48 PM, Antoine Jacoutet wrote > On Mon, Nov 21, 2016 at 05:34:35PM -0500, sven falempin wrote: > > Ansible is already managing pkg and service of openBSD , cool > > > > If one want to manage pf with it, and push or modify a few files, > > on must run - command:

Unnecessary goto in ip_output()

After the last IPSEC-related refactoring this goto no longer make sense. ok? Index: netinet/ip_output.c === RCS file: /cvs/src/sys/netinet/ip_output.c,v retrieving revision 1.330 diff -u -p -r1.330 ip_output.c ---

Re: switchd(8): negotiate versions with hello

> On 22.11.2016, at 16:12, Rafael Zalamena wrote: > > Teach switchd(8) how to negotiate protocol version using the hello bitmap > header. This way switchd(8) is able to fallback or use higher version using > the bitmap. > > This diff also prevents connections from

ip_input tweak

Keep blocks corresponding to the delivery path together. This helps when looking for differences with IPv6 and will make it easier to merge multicast checks. ok? Index: netinet/ip_input.c === RCS file:

ip6_input() refactoring

This diff merges two "#ifdef MROUTING" blocks. It's one more step towards splitting ip6_input() in two. Which is a requirement to unlock the forwarding path without messing with the receiving path. ok? Index: netinet6/ip6_input.c

switchd(8): negotiate versions with hello

Teach switchd(8) how to negotiate protocol version using the hello bitmap header. This way switchd(8) is able to fallback or use higher version using the bitmap. This diff also prevents connections from switching version in the middle of the operation. This is the first step before adding a

Re: reloading pf through ansible easy hook

I know the official validate command is pfctl -nf, but if you do so, you need to register the result of this task, then make one more conditional task to apply. This doubles your playbook execution time, which is not acceptable for me. -- Cordialement, Pierre BARDOU -Message

Re: reloading pf through ansible easy hook

On Tue, Nov 22, 2016 at 11:15:01AM +, BARDOU Pierre wrote: > Hello, > > - name: "Loading pf.conf" > template: src=pf.conf dest=/etc/ validate="pfctl -f %s" Fwiw, i find it nicer to validate with 'pfctl -nf' .. Landry

Re: pf af-to route output

On 22 November 2016 at 13:35, Alexander Bluhm wrote: > On Mon, Nov 21, 2016 at 10:47:34PM +0100, Mike Belopuhov wrote: >> On 21 November 2016 at 22:38, Alexandr Nedvedicky >> > The bluhm's change should not alter behavior of older code. >> Yes, it just adds something

Re: pf af-to route output

On 22 November 2016 at 13:35, Alexander Bluhm wrote: > On Mon, Nov 21, 2016 at 10:47:34PM +0100, Mike Belopuhov wrote: >> On 21 November 2016 at 22:38, Alexandr Nedvedicky >> > The bluhm's change should not alter behavior of older code. >> Yes, it just adds something

Re: pf af-to route output

> So we have a kernel implementation that might work for a feature > that makes sense. Especially the reply-to could be useful. But > the parser is too dumb. I think we should fix the parser and then > test the kernel. I absolutely agree. regards sasha

Re: pf af-to route output

On Mon, Nov 21, 2016 at 10:47:34PM +0100, Mike Belopuhov wrote: > On 21 November 2016 at 22:38, Alexandr Nedvedicky > > The bluhm's change should not alter behavior of older code. > Yes, it just adds something new. I did not try to add something new, I have preserved what was there in

umb string padding

This patch fixes a bug in the padding of umb strings. Instead of padding the right position, umb_padding() would always zero padding bytes at the beginning of the buffer. For the two callers of umb_addstr(), this won't hurt in umb_send_connect() since the first value in the buffer is the session

Re: ifioctl, pr_ctlinput, pr_slowtimo & pr_fasttimo

On Tue, Nov 22, 2016 at 11:39:32AM +0100, Martin Pieuchot wrote: > On 21/11/16(Mon) 20:07, Alexander Bluhm wrote: > > [...] > > NFS hits you again. nfs_boot_init() calls ifioctl(). Perhaps put > > the splsoftnet() inside ifioctl(). > > I'll put it inside nfs_boot() because the function also

Re: global mbuf memory limit

> Date: Tue, 22 Nov 2016 12:42:39 +1000 > From: David Gwynne > > right now pools that make up mbufs are each limited individually. > > the following diff instead has the mbuf layer have a global limit > on the amount of memory that can be allocated to the pools. this > is

Re: reloading pf through ansible easy hook

Hello, - name: "Loading pf.conf" template: src=pf.conf dest=/etc/ validate="pfctl -f %s" Works fine for me. Configuration is copied and loaded if correct, otherwise the rule file is not modified and not loaded (and the playbook fails with error). -- Cordialement, Pierre BARDOU -Message

Re: only free pool pages from the gc task

> Date: Tue, 22 Nov 2016 12:45:44 +1000 > From: David Gwynne > > at the moment pages can be freed on a pool_put call and from the gc. > > it is a bit unfair that pool_get may end up doing the heavy lifting > of allocating a pool page and pool_put wont have to do an

Re: bpf_mtap(9) w/o KERNEL_LOCK

On 13/09/16(Tue) 12:23, Martin Pieuchot wrote: > Here's the big scary diff I've been using for some months now to stop > grabbing the KERNEL_LOCK() in bpf_mtap(9). This has been originally > written to prevent lock ordering inside pf_test(). Now that we're > heading toward using a rwlock, we

Remove many splsoftnet() in ioctl(2) path

As soon as we ensure that ifioctl() is always called at IPL_SOFTNET we can remove all of these. Recursions still exist, but this is a good step forward. Index: net/if.c === RCS file: /cvs/src/sys/net/if.c,v retrieving revision 1.462

Re: ifioctl, pr_ctlinput, pr_slowtimo & pr_fasttimo

On 21/11/16(Mon) 20:07, Alexander Bluhm wrote: > [...] > NFS hits you again. nfs_boot_init() calls ifioctl(). Perhaps put > the splsoftnet() inside ifioctl(). I'll put it inside nfs_boot() because the function also iterate on structures that need to be protected. Note that this should not

Re: small indentation and spelling diff

On Mon, Nov 21, 2016 at 05:36:21PM -0700, Kyle Milz wrote: > - * everywhere. It wouldn't surprise me if several stacks accidently > + * everywhere. It wouldn't surprise me if several stacks accidentally /usr/share/dict/words has both variants. bluhm

Re: only free pool pages from the gc task

On 22/11/16(Tue) 12:45, David Gwynne wrote: > [...] > it is a bit unfair that pool_get may end up doing the heavy lifting > of allocating a pool page and pool_put wont have to do an equivalent > free, but we should try and minimise the amount of work done in > these hot paths. Any number,