Re: Remove some customization from our perl build

2020-04-10 Thread Theo de Raadt
Todd C. Miller wrote: > On Fri, 10 Apr 2020 18:17:33 -0700, Andrew Hewus Fresh wrote: > > > Recently it was pointed out that we don't link /usr/lib/libperl.so.* to > > libm the way is expected for code that also links to libperl. That led > > me to go digging again into the customization we hav

Re: Remove some customization from our perl build

2020-04-10 Thread Todd C . Miller
On Fri, 10 Apr 2020 18:17:33 -0700, Andrew Hewus Fresh wrote: > Recently it was pointed out that we don't link /usr/lib/libperl.so.* to > libm the way is expected for code that also links to libperl. That led > me to go digging again into the customization we have around the perl > build and gett

Remove some customization from our perl build

2020-04-10 Thread Andrew Hewus Fresh
Recently it was pointed out that we don't link /usr/lib/libperl.so.* to libm the way is expected for code that also links to libperl. That led me to go digging again into the customization we have around the perl build and getting terribly confused. That did somewhat clear up after reading more a

__hldtoa broken for ld128

2020-04-10 Thread enh
this was found by fuzzing the LLVM __cxa_demangle on an ld128 Android system using hwasan, but it turns out no to simply be a buffer overflow --- the results are just wrong. (which shows how much anyone uses ld128 in conjunction with %a!) this was the minimized test case: free(__cxa_demangle("1\0

Cache incoherent ACPI support

2020-04-10 Thread Mark Kettenis
Some semi-recent ACPI revision introduced the _CCA method. This method indicates whether DMA is cache-coherent for a device. This isn't really relevant on i386/amd64 since its busses are pretty much always fully cache-coherent. But on amr64 things are different. Server machines typically have co

xhci(4) and acpi(4)

2020-04-10 Thread Mark Kettenis
The Rapsberry Pi4 UEFI firmware (in ACPI mode) uses a QWord() resource descriptor for the address. ok? P.S. I still plan to move this parsing code into something a bit more generic at some point instead of replicating slightly different versions in each driver. Index: dev/acpi/xhci_ac

pppx(4): kill useless rwlocks

2020-04-10 Thread Vitaliy Makkoveev
Subj. Index: net/if_pppx.c === RCS file: /cvs/src/sys/net/if_pppx.c,v retrieving revision 1.83 diff -u -p -r1.83 if_pppx.c --- net/if_pppx.c 10 Apr 2020 07:36:52 - 1.83 +++ net/if_pppx.c 10 Apr 2020 11:16:53 -000

kqueue_scan() refactoring

2020-04-10 Thread Martin Pieuchot
Diff below reduces kqueue_scan() to the collect of events on a given kqueue and let its caller, sys_kevent(), responsible for the copyout(9). Apart from the code simplification, this refactoring clearly separates kqueue_scan() from the syscall logic. That should allow us to re-use the function in

em(4) and FOREACH_QUEUE()

2020-04-10 Thread Martin Pieuchot
Unlike ix(4) the em(4) driver still needs some more code shuffling in order to be ready for multi-queue support. The diff below introduces the macro FOREACH_QUEUE() and use it where some per-queue setup is required. It only convert the trivial places and whitespace changes aren't included to ease

switch powerpc to MI mplock

2020-04-10 Thread Martin Pieuchot
In order to reduce the differences with other architecture and to be able to use WITNESS on powerpc I'm proposing the diff below that makes use of the MI mp (ticket) lock implementation for powerpc. This has been tested by Peter J. Philipp but I'd like to have more tests before proceeding. As exp

Re: powerpc: mplock & WITNESS

2020-04-10 Thread Martin Pieuchot
On 09/04/20(Thu) 22:58, George Koehler wrote: > On Thu, 9 Apr 2020 20:05:34 +0200 > Martin Pieuchot wrote: > [...] > In the trace, #0 and #1 are wrong, but the rest of the trace looks > good enough for WITNESS. I added an artificial lock order reversal to > ums(4) for WITNESS to catch. I got th

Re: openssl(1) x509, change in serial number output between 6.5 and 6.6

2020-04-10 Thread Kinichiro Inoguchi
On Thu, Apr 09, 2020 at 07:44:51PM +0100, Stuart Henderson wrote: > On 2020/04/09 20:13, Theo Buehler wrote: > > On Thu, Apr 09, 2020 at 05:56:55PM +0100, Stuart Henderson wrote: > > > Not new - this happened somewhere between 6.5 and 6.6 - but some > > > certificates are now showing up with bad se