Re: armv7 ABI fix

2018-02-27 Thread Peter Hessler
On 2018 Feb 27 (Tue) at 22:04:15 +0100 (+0100), Mark Kettenis wrote: :The "new" AAPCS-based ABI that we have been using on armv7 for a while :now requires various 64-bit types to be aligned on an 8-byte boundary. :Unfortunately we didn't realize this when we switched and didn't :adjust the

Re: armv7 ABI fix

2018-02-27 Thread Otto Moerbeek
On Tue, Feb 27, 2018 at 10:04:15PM +0100, Mark Kettenis wrote: > The "new" AAPCS-based ABI that we have been using on armv7 for a while > now requires various 64-bit types to be aligned on an 8-byte boundary. > Unfortunately we didn't realize this when we switched and didn't > adjust the

Re: [PATCH] Fix Comment Line Unfolding in make/lowparse.c

2018-02-27 Thread William Ahern
On Fri, Feb 23, 2018 at 12:27:14PM -0800, William Ahern wrote: > The routine skip_empty_lines_and_read_char() is an optimization to skip over > blocks of comment lines. When it reads an unescaped '#' it uses the helper > routine skip_to_end_of_line(). But skip_to_end_of_line() doesn't fold lines >

Re: openssl.1 diff

2018-02-27 Thread Jason McIntyre
On Tue, Feb 27, 2018 at 11:04:10PM +0100, Holger Mikolon wrote: > > hi. > > > > i wonder whether we could more simply just use the date format [YY]YY, > > explain the 2050 cutoff, and forget about mentioning asn.1 time > > structures. > > > > or do you think there is a practical reason why the

Re: openssl.1 diff

2018-02-27 Thread Holger Mikolon
> hi. > > i wonder whether we could more simply just use the date format [YY]YY, > explain the 2050 cutoff, and forget about mentioning asn.1 time > structures. > > or do you think there is a practical reason why the user would need to > know it? i suspect not. Actually the mentioning of the

Re: armv7 really isn't a strict-alignment architecture

2018-02-27 Thread Brandon Bergren
Other stuff from my local diffs: * kernel_text should really be in locore0.S, or in the linker script, right now I suspect that it would cause random ddb issues because it isn't actually pointing at the start of the kernel text currently. * sys/arch/armv7/armv7/armv7_machdep.c: - msgbufphys

Re: armv7 ABI fix

2018-02-27 Thread Theo de Raadt
>However, this triggers a flag day. It changes the CMSG ABI, which >means that file descriptor passing breaks as soon as you boot a new >kernel with old userland. That sucks since many of our daemons use >file descriptor passing, including sshd. Can we deal with yet another >ABI break on armv7?

make ifnet if_rtrequest functions return success

2018-02-27 Thread David Gwynne
ethernet likes to attach a struct to RTF_LLINFO routes in things like ether_rtrequest/arp_rtrequest, and then deref that struct unconditionally in a ether_output/arpresolve. if that struct cannot be allocated in arp_rtrequest, we should report failure and let the routing layer unwind. this is a

Re: armv7 really isn't a strict-alignment architecture

2018-02-27 Thread Brandon Bergren
On Tue, Feb 27, 2018, at 3:40 PM, Mark Kettenis wrote: > > Date: Tue, 27 Feb 2018 22:30:43 +0100 (CET) > > From: Mark Kettenis > > > > > From: Brandon Bergren > > > Date: Tue, 27 Feb 2018 15:05:43 -0600 > > > > > > Oh geez, I just figured

Re: armv7 really isn't a strict-alignment architecture

2018-02-27 Thread Mark Kettenis
> Date: Tue, 27 Feb 2018 22:30:43 +0100 (CET) > From: Mark Kettenis > > > From: Brandon Bergren > > Date: Tue, 27 Feb 2018 15:05:43 -0600 > > > > Oh geez, I just figured out what my own crash was -- svcstk is not > > being aligned properly in

Re: openssl.1 diff

2018-02-27 Thread Jason McIntyre
On Tue, Feb 27, 2018 at 08:54:48PM +0100, Holger Mikolon wrote: > When playing with "openssl ca" with various validity end dates I could > not manage end dates of 2050 or later - until I started reading code and > the RFC 5280. As far as I understand it now (and is confirmed by various > tests),

Re: armv7 really isn't a strict-alignment architecture

2018-02-27 Thread Mark Kettenis
> From: Brandon Bergren > Date: Tue, 27 Feb 2018 15:05:43 -0600 > > Oh geez, I just figured out what my own crash was -- svcstk is not > being aligned properly in sys/arch/arm/arm/locore.S, so depending on > the link order, the address of the service stack could be in

Re: armv7 really isn't a strict-alignment architecture

2018-02-27 Thread Brandon Bergren
Oh geez, I just figured out what my own crash was -- svcstk is not being aligned properly in sys/arch/arm/arm/locore.S, so depending on the link order, the address of the service stack could be in some random place in .bss. I *think* it's supposed to be .align 8 anyway to be

armv7 ABI fix

2018-02-27 Thread Mark Kettenis
The "new" AAPCS-based ABI that we have been using on armv7 for a while now requires various 64-bit types to be aligned on an 8-byte boundary. Unfortunately we didn't realize this when we switched and didn't adjust the definition of _ALIGNBYTES accordingly. The diff below fixes that. However,

Re: armv7 really isn't a strict-alignment architecture

2018-02-27 Thread Mark Kettenis
> Date: Tue, 27 Feb 2018 23:09:24 +1100 > From: Jonathan Gray > > On Thu, Feb 22, 2018 at 10:51:12PM +0100, Mark Kettenis wrote: > > I hate to loose yet another strict-alignment canary, but the reality > > is that the rest of the world assumes that armv7 supports unaligned > >

openssl.1 diff

2018-02-27 Thread Holger Mikolon
When playing with "openssl ca" with various validity end dates I could not manage end dates of 2050 or later - until I started reading code and the RFC 5280. As far as I understand it now (and is confirmed by various tests), the openssl parameter "-enddate" expects one of two date/time formats -

Re: times(3): return monotonically increasing values

2018-02-27 Thread Todd C. Miller
On Mon, 26 Feb 2018 19:12:20 -0600, Scott Cheloha wrote: > Reading the latest POSIX description for times(3): > > > Upon successful completion, times() shall return the elapsed > > real time, in clock ticks, since an arbitrary point in the past > > (for example, system start-up time). This point

Re: armv7 really isn't a strict-alignment architecture

2018-02-27 Thread Jonathan Gray
On Thu, Feb 22, 2018 at 10:51:12PM +0100, Mark Kettenis wrote: > I hate to loose yet another strict-alignment canary, but the reality > is that the rest of the world assumes that armv7 supports unaligned > access which means that compilers generate code that assumes this > works when compiling

[ed] fixing the list command

2018-02-27 Thread Nils Reuße
Hi there, the 'l' command in base ed currently does not mark the end of line with a '$'. This is documented in the man page (POSIX wants each '$' escaped, and a final '$' at EOL). Interestingly, the code to mark EOL is already there, just hidden by the BACKWARDS flag ed is compiled with.

Re: unhandled firmware response in iwm

2018-02-27 Thread Jan Schreiber
On 02/27/18 09:06, Stefan Sperling wrote: > On Mon, Feb 26, 2018 at 11:55:34PM +0100, j...@posteo.de wrote: >> When connecting to a wifi network messages like "iwm0: unhandled firmware >> response 0xff/0xb810 rx ring" appear. >> After looking at https://patchwork.kernel.org/patch/9869017/ I

Re: Add RTL8211F support to rgephy(4)

2018-02-27 Thread Jonathan Gray
On Tue, Feb 27, 2018 at 10:22:46AM +0100, Mark Kettenis wrote: > > Date: Tue, 27 Feb 2018 18:47:42 +1100 > > From: Jonathan Gray > > > > On Mon, Feb 26, 2018 at 10:08:12PM +0100, Mark Kettenis wrote: > > > There is a new rgepy(4) variant (rev. 6, RTL8211F). Unfortunately > > >

Re: unhandled firmware response in iwm

2018-02-27 Thread Stefan Sperling
On Mon, Feb 26, 2018 at 11:55:34PM +0100, j...@posteo.de wrote: > When connecting to a wifi network messages like "iwm0: unhandled firmware > response 0xff/0xb810 rx ring" appear. > After looking at https://patchwork.kernel.org/patch/9869017/ I came up with > following patch. > The link also