> > The comment says, AS A WHOLE:
> >
> > /*
> > * Entropy collection via /dev/urandom and sysctl have failed.
> > *
> > * No other API exists for collecting entropy. See the large
> > * comment block above.
> > *
> > * We have very fe
> The comment says, AS A WHOLE:
>
> /*
> * Entropy collection via /dev/urandom and sysctl have failed.
> *
> * No other API exists for collecting entropy. See the large
> * comment block above.
> *
> * We have very few options:
>
First, we don't need to grab and ungrab the lock just to check
getnewvode's error status. No race there.
Second, since we're already prepared to deal with losing a race and
retrying, we can move the blocking pool_get operation out of the lock,
too. Fewer pileups in the event the code does block.
>On 12/18/2014 06:29 PM, Theo de Raadt wrote:
>>> On 12/18/2014 12:14 AM, Theo de Raadt wrote:
> getentropy*.c: "cannot call abort() because some systems have unsafe
> corefiles"
> arc4random.c: "if(_rs_allocate(...) == -1) abort();"
>
> Am I missing any difference between the t
Hi!
The diff for extracting memory ranges from ACPI was obviously not tested
with ACPI disabled...so we definitely have to check if the values in
pcimem_range make some sense. The diff below now uses the old values in
case ACPI is disabled or does not return valid values.
I hope this is somewhat
On 2014/12/18 15:12, Ted Unangst wrote:
> There could maybe be ports fallout
relayd-updateconf.
Change all the bcopy to memcpy. "Should be safe." Could even be faster.
Looking for a few tests to make sure.
Index: softraid.c
===
RCS file: /cvs/src/sys/dev/softraid.c,v
retrieving revision 1.346
diff -u -p -r1.346 softraid.c
--- s
On Thu, Dec 18, 2014 at 03:12:39PM -0500, Ted Unangst wrote:
> This is pending reyk's relayd patch, which I think is coming soon.
> After that, we don't need sys/hash.h anywhere in src.
>
relayd is in...
> There could maybe be ports fallout, but that seems unlikely in most
> cases because this i
This is pending reyk's relayd patch, which I think is coming soon.
After that, we don't need sys/hash.h anywhere in src.
There could maybe be ports fallout, but that seems unlikely in most
cases because this is an openbsd specific header. Any such ports are
probably best updated to use siphash any
On Thu, Dec 18, 2014 at 14:38, David Higgs wrote:
>
> On Dec 18, 2014, at 1:48 PM, David Higgs wrote:
>
>> Bah. One of those should be (muAh).
>>
Here's the full microdiff.
ok? not ok? mu?
Index: sensors.h
===
RCS file: /cvs/src
On Thu, Dec 18, 2014 at 13:23, David Higgs wrote:
> For consistency.
>
> --david
>
>
> Index: sensors.h
> ===
> RCS file: /cvs/src/sys/sys/sensors.h,v
> retrieving revision 1.33
> diff -u -p -r1.33 sensors.h
> --- sensors.h 4 Nov 20
On Dec 18, 2014, at 1:48 PM, David Higgs wrote:
> Bah. One of those should be (muAh).
>
Take two.
--david
Index: sensors.h
===
RCS file: /cvs/src/sys/sys/sensors.h,v
retrieving revision 1.33
diff -u -p -r1.33 sensors.h
--- sens
Use siphash in bridge. I "inlined" the key in if_bridge.h instead of
creating a dependency on siphash.h.
(reminder diffs are outstanding for ospfd, ospf6d, and bgpd.)
Index: if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
re
Bah. One of those should be (muAh).
--david
For consistency.
--david
Index: sensors.h
===
RCS file: /cvs/src/sys/sys/sensors.h,v
retrieving revision 1.33
diff -u -p -r1.33 sensors.h
--- sensors.h 4 Nov 2013 02:41:49 - 1.33
+++ sensors.h 18 Dec 2014 18:16:07 -000
> On 12/18/2014 12:14 AM, Theo de Raadt wrote:
> >> getentropy*.c: "cannot call abort() because some systems have unsafe
> >> corefiles"
> >> arc4random.c: "if(_rs_allocate(...) == -1) abort();"
> >>
> >> Am I missing any difference between the two cases?
> >> (brain,cvsweb,google+gmane weren't any
On 2014-12-17 17:44, Todd C. Miller wrote:
It would be helpful if you could break the diff up into smaller
logical pieces. For instance, one diff for the SLIST changes,
another for general cleanup and a third for the glob() changes.
- todd
Ok, my bad. I re-did the changes in stages using qu
17 matches
Mail list logo
