Re: arm64 setjmp/longjmp signal mask storage error

On Tue, Mar 07, 2017 at 01:44:19AM -0500, Dale Rahn wrote: > Setjmp, longjmp was converted from calling sigprocmask to invoking > sigprocmask directly. The ABI for the function call and the syscall > are not the same and the register manipulation code was not updated > in the change. > > This

Re: arm64 SMP support, diff #3/5

On Thu, Feb 23, 2017 at 01:03:57PM +1100, Jonathan Gray wrote: > On Wed, Feb 22, 2017 at 06:45:52PM -0500, Dale Rahn wrote: > > Add psci 2.0 features to spin up/down/suspend processors. > > > > This change uses extern weak symbols to determine if the platform supports > > the

Re: ntp_update_second - removed unused var

David Hill writes: > Hello - > > time_t *sec is unused in ntp_update_second. > OK? ok jca@ > Index: kern/kern_tc.c > === > RCS file: /cvs/src/sys/kern/kern_tc.c,v > retrieving revision 1.30 > diff -u -p -r1.30

Re: in_pcballoc IPv6 hash

Alexander Bluhm writes: > Hi, > > Initially all inpcb, including the IPv6 ones, are hooked into the > IPv4 hash. They cannot be used before bind(2) and then they are > rehashed and rehooked, so this is not noticed. Nevertheless I think > this is a bug and they should

arm64 setjmp/longjmp signal mask storage error

Setjmp, longjmp was converted from calling sigprocmask to invoking sigprocmask directly. The ABI for the function call and the syscall are not the same and the register manipulation code was not updated in the change. This diff moves the jmpbuf to x2 for the duration of the sigprocmask syscall

Re: 61.html - document resolver(3) support for EDNS0 and DNSSEC

I have committed a similar diff, thanks. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

Re: 11n support for athn(4)

Stefan Sperling writes: > On Mon, Mar 06, 2017 at 07:36:21AM +0200, Timo Myyrä wrote: > >> Did some tcpbench testing and got following results: >> Each test run with: tcpbench -s || tcpbench -t 15 commands. >> Host AP: apu 2b4 with athn, client = thinkpad t430s with iwn

Re: Preserve original pf flow classification

> On 7 Mar 2017, at 05:27, Mike Belopuhov wrote: > > There's no need to overwrite original flow ID assigned on > input so that it remains stable throughout the life of a > packet. The rationale is that output processing may split, > encapsulate or obfuscate a single stream

acpisbs/acpibat

In case the DSDT provides interfaces for both a Smart Battery and a normal one, probe for acpisbs first, if it attaches, make acpibat not match. Index: dev/acpi/acpi.c === RCS file: /cvs/src/sys/dev/acpi/acpi.c,v retrieving revision

Re: priq: convert to mbuf lists

> On 2 Mar 2017, at 21:19, Mike Belopuhov wrote: > > On Thu, Mar 02, 2017 at 10:11 +0100, Martin Pieuchot wrote: >> On 02/03/17(Thu) 01:16, Mike Belopuhov wrote: >>> On 2 March 2017 at 00:56, David Gwynne wrote: > On 2 Mar 2017, at 06:43, Mike

decryption failed or bad record mac (was: tlsv1 alert decrypt error)

Thanks for moving the thread to the correct place! * Bob Beck [2017-03-06 15:49]: And as joel mentioned, a fix is already arriving for this - there was a bug in SSLv2 compatible handshake initiation, Joel sent me a patch which appeared here:

Re: tlsv1 alert decrypt error

And as joel mentioned, a fix is already arriving for this - there was a bug in SSLv2 compatible handshake initiation, and Paypal still has it enabled... (yeeuch) On Mon, Mar 6, 2017 at 3:48 PM, Bob Beck wrote: > > Move it to tech@ from misc.. not libressl.. libressl is not

Re: tlsv1 alert decrypt error

Move it to tech@ from misc.. not libressl.. libressl is not special ;) On Mon, Mar 6, 2017 at 3:21 PM, Kirill Miazine wrote: > Moving to libressl@ from misc@, as it's a LibreSSL issue. > > * Joel Sing [2017-03-05 23:01]: > > On Thursday 02 March 2017 13:28:08 Kirill Miazine

synaptics(4): multitouch input and hysteresis

While preparing and testing some changes in ubcmtp I found a bug in wsconscomm that may affect two-finger touches on "noisy" MT devices, that is, on devices that constantly report small deltas of the touch positions even if there is no noticeable movement. Whenever the contact count or the

Re: {tc,ud}btable & NET_LOCK()

On Mon, Mar 06, 2017 at 12:13:48PM +0100, Martin Pieuchot wrote: > In sysctl_file() splnet() is no longer what we want. Arguably the > KERNEL_LOCK() should be enough, but since pf(4) is messing with these > tables, and nobody turned this part of pf(4) MP, let's require the > NET_LOCK(). > > ok?

Re: take PRU_ATTACH out of usrreq

On Sun, Mar 05, 2017 at 10:54:39AM +0100, Claudio Jeker wrote: > Here is an updated version of the PRU_ATTACH diff. I looked at the pfkey > code and decided to only do the minimum now. I will go in afterwards and > kill the dynamic fiddling in there. There is no reason for all this > complication

Preserve original pf flow classification

There's no need to overwrite original flow ID assigned on input so that it remains stable throughout the life of a packet. The rationale is that output processing may split, encapsulate or obfuscate a single stream which makes the changed flow ID useless for purposes of flow control, for instance

Re: PF_ROUTE vs NET_LOCK(), take 2

On Mon, Mar 06, 2017 at 01:33:19PM +0100, Martin Pieuchot wrote: > After some refactoring, here's the updated diff to take the routing > sockets out of the NET_LOCK(). > > ok? OK bluhm@ > > Index: net/raw_usrreq.c > === > RCS

Re: route_output M_WAITOK

On Sun, Mar 05, 2017 at 12:22:57PM +0100, Claudio Jeker wrote: > On Fri, Mar 03, 2017 at 08:16:43AM +0100, Martin Pieuchot wrote: > > On 03/03/17(Fri) 01:40, Alexander Bluhm wrote: > > > On Thu, Mar 02, 2017 at 10:55:41AM +0100, Martin Pieuchot wrote: > > > > Actually the malloc(9) could be

Re: integer overflow in PF may lead to dropped connections

On Mon, Mar 06, 2017 at 14:46 +0100, Claudio Jeker wrote: > On Mon, Mar 06, 2017 at 01:04:28PM +0100, Mike Belopuhov wrote: > > On Fri, Mar 03, 2017 at 16:58 +0100, mathieu.bl...@cea.fr wrote: > > > Hi, > > > > > > here is a patch which fixes an integer overflow in the computation of > > >

PF_ROUTE vs NET_LOCK(), take 2

After some refactoring, here's the updated diff to take the routing sockets out of the NET_LOCK(). ok? Index: net/raw_usrreq.c === RCS file: /cvs/src/sys/net/raw_usrreq.c,v retrieving revision 1.29 diff -u -p -r1.29 raw_usrreq.c ---

Re: integer overflow in PF may lead to dropped connections

On Fri, Mar 03, 2017 at 16:58 +0100, mathieu.bl...@cea.fr wrote: > Hi, > > here is a patch which fixes an integer overflow in the computation of > adaptive timeouts. The effect of this integer overflow is that > depending on timeout values, legitimate established connection states > can be

{tc,ud}btable & NET_LOCK()

In sysctl_file() splnet() is no longer what we want. Arguably the KERNEL_LOCK() should be enough, but since pf(4) is messing with these tables, and nobody turned this part of pf(4) MP, let's require the NET_LOCK(). ok? Index: kern/kern_sysctl.c

Re: 11n support for athn(4)

On Mon, Mar 06, 2017 at 07:36:21AM +0200, Timo Myyrä wrote: > Did some tcpbench testing and got following results: > Each test run with: tcpbench -s || tcpbench -t 15 commands. > Host AP: apu 2b4 with athn, client = thinkpad t430s with iwn (OpenBSD) > > channel 9 running old snapshot etc: > 11n

integer overflow in PF may lead to dropped connections

Hi, here is a patch which fixes an integer overflow in the computation of adaptive timeouts. The effect of this integer overflow is that depending on timeout values, legitimate established connection states can be evicted immediately (although other states with shorter timeouts would be available