Re: [PATCH] socppc discontinued in 61.html

Hi Bryan, since nobody else answered, and even though i don't know that much about hardware support: I don't think your patch should be committed. https://www.openbsd.org/socppc.html says: The OpenBSD/socppc port was discontinued after the 5.8 release. In that sense, the 6.1 release does

Re: [PATCH] socppc discontinued in 61.html

On Fri, Mar 17, 2017 at 05:28:59PM +0100, Ingo Schwarze wrote: > Hi Bryan, > > since nobody else answered, and even though i don't know that > much about hardware support: I don't think your patch should be > committed. > > https://www.openbsd.org/socppc.html > > says: > The OpenBSD/socppc

Re: arm64 kernel W^X

> Date: Fri, 17 Mar 2017 19:07:16 +0100 > From: Patrick Wildt > > On Fri, Mar 17, 2017 at 06:42:38PM +0100, Mark Kettenis wrote: > > The diff below introduces kernel W^X on arm64. It changes the linker > > script to align the RX, R and RW segments on a 2MB boundary such that

Re: arm64: Remove early ASID allocation

> Date: Fri, 17 Mar 2017 16:00:53 -0400 > From: Dale Rahn > > Do not preallocate the asid, wait until it is allcoated in pmap_setttb() > Simplifies the code by only having one location that does the asid > allocation. > > There is no need to allocate the ASID direclty in

Re: arm64: allocate an empty user map for kernel mode.

> Date: Fri, 17 Mar 2017 16:12:13 -0400 > From: Dale Rahn > > When the kernel switches to the kernel pmap, the pmap had been previously > leaving the ttbr0 unmodified as the kernel pmap space is all accesse thru > ttbr1. Well at one point the ttbr0 was updated with the ttbr1

arm64 kernel W^X

The diff below introduces kernel W^X on arm64. It changes the linker script to align the RX, R and RW segments on a 2MB boundary such that we can continue to use block mappings for the kernel. Then it adds some additional linker generated symbols that allow us to determine whether a block is

Re: arm64 kernel W^X

On Fri, Mar 17, 2017 at 06:42:38PM +0100, Mark Kettenis wrote: > The diff below introduces kernel W^X on arm64. It changes the linker > script to align the RX, R and RW segments on a 2MB boundary such that > we can continue to use block mappings for the kernel. Then it adds > some additional

arm64: allocate an empty user map for kernel mode.

When the kernel switches to the kernel pmap, the pmap had been previously leaving the ttbr0 unmodified as the kernel pmap space is all accesse thru ttbr1. Well at one point the ttbr0 was updated with the ttbr1 content, but that caused MASSIVE failures. This diff add an allocation of a

arm64: Remove early ASID allocation

Do not preallocate the asid, wait until it is allcoated in pmap_setttb() Simplifies the code by only having one location that does the asid allocation. There is no need to allocate the ASID direclty in pmap_activate as the code in pmap setttb will do that allocation so this code is just

Re: SVM instructions

> Date: Fri, 17 Mar 2017 07:00:08 +0100 > From: Joerg Sonnenberger > > On Wed, Mar 15, 2017 at 09:05:56PM +0100, Mark Kettenis wrote: > > Clang only accepts SVM instructions with explicit operands, for > > example: > > > > vmload %rax > > You might want to look at the aliases

Re: Sync nfs_connect w/ sys_connect

On 07/03/17(Tue) 10:57, Martin Pieuchot wrote: > This code is mostly a copy of what's done in sys_connect(), so sync it > to use solock()/sosleep()/sounlock() instead of splsoftnet()/splx(). > > ok? Anyone? > > Index: nfs/nfs_socket.c >

Re: Unneeded splnet()/splx() in carp(4)

On 07/03/17(Tue) 11:08, Martin Pieuchot wrote: > carp(4), as a pseudo-interface, is always executed in the 'softnet' > thread. Using splnet()/splx() might have been relevant when link-state > handlers where directly executed from hardware interrupt handlers. But > nowadays everything is run

Re: Sync nfs_connect w/ sys_connect

On Tue, Mar 07, 2017 at 10:57:52AM +0100, Martin Pieuchot wrote: > This code is mostly a copy of what's done in sys_connect(), so sync it > to use solock()/sosleep()/sounlock() instead of splsoftnet()/splx(). > > ok? OK bluhm@ > > Index: nfs/nfs_socket.c >

Re: syslogd log_debug

On Fri, Mar 17, 2017 at 08:07:38AM +0100, Martin Pieuchot wrote: > On 17/03/17(Fri) 02:09, Alexander Bluhm wrote: > > Replace logdebug() with generic log_debug() from log.c. Implement > > log_debugadd() to construct debug message incrementally. > > FWIW the idea was to keep log.c identical in

Re: Unneeded splnet()/splx() in carp(4)

On 7 March 2017 at 11:08, Martin Pieuchot wrote: > carp(4), as a pseudo-interface, is always executed in the 'softnet' > thread. Using splnet()/splx() might have been relevant when link-state > handlers where directly executed from hardware interrupt handlers. But > nowadays

pf: percpu anchor stacks

Hi, to step into and out of pf(4) anchors, pf(4) uses a temporary stack that is a global variable. Now once we run pf_test_rule() in parallel and an anchor is evaluated in parallel, the global stack would be used concurrently, which can lead to panics. To solve this issue this diff allocates a

Re: roff(7) man page not rendering properly in its entirety on man.openbsd.org

Hi, Raf Czlonka wrote on Thu, Mar 16, 2017 at 10:56:23PM +: > While looking at several manual pages on man.openbsd.org, Thanks for testing, ... > I've noticed that roff(7) man page does not render properly > in its entirety, ... and for reporting. > No idea what might be causing the

Re: Unneeded splnet()/splx() in carp(4)

On Tue, Mar 07, 2017 at 11:08:43AM +0100, Martin Pieuchot wrote: > carp(4), as a pseudo-interface, is always executed in the 'softnet' > thread. Using splnet()/splx() might have been relevant when link-state > handlers where directly executed from hardware interrupt handlers. But > nowadays

Re: SVM instructions

On Wed, Mar 15, 2017 at 09:05:56PM +0100, Mark Kettenis wrote: > Clang only accepts SVM instructions with explicit operands, for > example: > > vmload %rax You might want to look at the aliases e.g. for monitor/mwait. Should be pretty easy to extend as long as we are talkign about pure