On Tue, Nov 04, 2014 at 02:59:17AM +1100, Bruce Evans wrote:
> On Mon, 3 Nov 2014, Konstantin Belousov wrote:
>
> > On Mon, Nov 03, 2014 at 11:53:26AM +1100, Bruce Evans wrote:
> >> On Sun, 2 Nov 2014, Ian Lepore wrote:
> >>
> >>> On Sun, 2014-11-02 at 12:27 -0800, Xin Li wrote:
> -BEGIN
On Mon, 3 Nov 2014, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/2/14 5:13 PM, Bruce Evans wrote:
% - % -KASSERT(random_adaptor != NULL, ("No active random
adaptor in %s", __func__)); % } % % void
Lots of style bugs (long lines, use of the __func__ obfuscation,
an
On Mon, 3 Nov 2014, Konstantin Belousov wrote:
On Mon, Nov 03, 2014 at 11:53:26AM +1100, Bruce Evans wrote:
On Sun, 2 Nov 2014, Ian Lepore wrote:
On Sun, 2014-11-02 at 12:27 -0800, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi, Mark,
I'd like to propose the attached patc
On Mon, Nov 03, 2014 at 11:53:26AM +1100, Bruce Evans wrote:
> On Sun, 2 Nov 2014, Ian Lepore wrote:
>
> > On Sun, 2014-11-02 at 12:27 -0800, Xin Li wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >> Hi, Mark,
> >>
> >> I'd like to propose the attached patch for review. It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/2/14 5:13 PM, Bruce Evans wrote:
> % - % -KASSERT(random_adaptor != NULL, ("No active random
> adaptor in %s", __func__)); % } % % void
>
> Lots of style bugs (long lines, use of the __func__ obfuscation,
> and general verboseness).
Wha
On Sun, 2 Nov 2014, Xin Li wrote:
Another revision to make Jilles happy -- changed 'block' to 'randrd'
and 'randwr', I saw his email but forgot to make the change.
% Index: sys/dev/random/random_adaptors.c
% ===
% --- sys/dev/ra
On Sun, 2 Nov 2014, Ian Lepore wrote:
On Sun, 2014-11-02 at 12:27 -0800, Xin Li wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi, Mark,
I'd like to propose the attached patch for review. It replaces
tsleep's with sx_sleep's, then checks the return value and quit the loop.
It still
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Another revision to make Jilles happy -- changed 'block' to 'randrd'
and 'randwr', I saw his email but forgot to make the change.
Cheers,
- --
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN P
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/02/14 12:53, Ian Lepore wrote:
> On Sun, 2014-11-02 at 12:27 -0800, Xin Li wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>>
>> Hi, Mark,
>>
>> I'd like to propose the attached patch for review. It replaces
>> tsleep's with sx_sl
On Sun, Nov 02, 2014 at 12:27:32PM -0800, Xin Li wrote:
> I'd like to propose the attached patch for review. It replaces
> tsleep's with sx_sleep's, then checks the return value and quit the
> loop.
While you're there, please adjust the wait messages from "block" to
something like "randrd" and "r
On Sun, 2014-11-02 at 12:27 -0800, Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi, Mark,
>
> I'd like to propose the attached patch for review. It replaces
> tsleep's with sx_sleep's, then checks the return value and quit the loop.
>
> Cheers,
> - --
It still doesn't
This look visually OK to me.
I’ll run it locally, but it needs So permission to commit. I guess
you can self-certify, right? :-)
M
> On 2 Nov 2014, at 20:27, Xin Li wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi, Mark,
>
> I'd like to propose the attached patch for revi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi, Mark,
I'd like to propose the attached patch for review. It replaces
tsleep's with sx_sleep's, then checks the return value and quit the loop.
Cheers,
- --
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free
On Sun, Nov 02, 2014 at 12:04:17PM -0800, Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 11/02/14 11:56, Mark R V Murray wrote:
> >
> >> On 2 Nov 2014, at 19:46, Konstantin Belousov
> >> wrote:
> >>
> >>> I don???t quite follow what you mean, but it sounds like you
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/02/14 11:56, Mark R V Murray wrote:
>
>> On 2 Nov 2014, at 19:46, Konstantin Belousov
>> wrote:
>>
>>> I don???t quite follow what you mean, but it sounds like you
>>> understand the problem. Could you please explain with a bit
>>> more deta
> On 2 Nov 2014, at 19:46, Konstantin Belousov wrote:
>
>> I don???t quite follow what you mean, but it sounds like you understand
>> the problem. Could you please explain with a bit more detail?
>
> Which problem ? There are two.
>
> One is the Adrian' complain. tsleep(9) catches signals, and
On Sun, Nov 02, 2014 at 12:15:00PM -0700, Ian Lepore wrote:
> On Sun, 2014-11-02 at 11:05 -0800, Adrian Chadd wrote:
> > [snip all the conversation]
> >
> > Ok. There's still a problem that I can trigger by trying to Ctrl-C a
> > process that's blocked reading for randomness. I'll try to chase up
On Sun, Nov 02, 2014 at 07:24:13PM +, Mark R V Murray wrote:
>
> > On 2 Nov 2014, at 19:20, Konstantin Belousov wrote:
> >
> > On Sun, Nov 02, 2014 at 11:05:27AM -0800, Adrian Chadd wrote:
> >> [snip all the conversation]
> >>
> >> Ok. There's still a problem that I can trigger by trying to
> On 2 Nov 2014, at 19:20, Konstantin Belousov wrote:
>
> On Sun, Nov 02, 2014 at 11:05:27AM -0800, Adrian Chadd wrote:
>> [snip all the conversation]
>>
>> Ok. There's still a problem that I can trigger by trying to Ctrl-C a
>> process that's blocked reading for randomness. I'll try to chase u
On Sun, Nov 02, 2014 at 11:05:27AM -0800, Adrian Chadd wrote:
> [snip all the conversation]
>
> Ok. There's still a problem that I can trigger by trying to Ctrl-C a
> process that's blocked reading for randomness. I'll try to chase up
> more details about and file a PR about it.
>
> The unfortuna
On Sun, 2014-11-02 at 11:05 -0800, Adrian Chadd wrote:
> [snip all the conversation]
>
> Ok. There's still a problem that I can trigger by trying to Ctrl-C a
> process that's blocked reading for randomness. I'll try to chase up
> more details about and file a PR about it.
>
> The unfortunate part
[snip all the conversation]
Ok. There's still a problem that I can trigger by trying to Ctrl-C a
process that's blocked reading for randomness. I'll try to chase up
more details about and file a PR about it.
The unfortunate part is that the kernel side stack trace of the
offending / hung process
> On 2 Nov 2014, at 13:22, Ian Lepore wrote:
>
> On Sun, 2014-11-02 at 09:45 +, Mark R V Murray wrote:
>> Hi DES,
>>
>> I´m scared witless of this being on-by-default, for the reason given in the
>> removed comment. I´d much prefer to see it only turned on if a kernel option
>> is set, an
> On 2 Nov 2014, at 12:42, Dag-Erling Smørgrav wrote:
>
> Mark R V Murray writes:
>> DES’s change makes no difference in a Tier-1 platform, except
>> potentially hiding a security problem.
>
> I will assume that you did not read the discussion that lead up to my
> commits, because if you did,
On Sun, 2014-11-02 at 09:45 +, Mark R V Murray wrote:
> Hi DES,
>
> I’m scared witless of this being on-by-default, for the reason given in the
> removed comment. I’d much prefer to see it only turned on if a kernel option
> is set, and the embedded folks /et al/ can use that.
>
> Please re
> On 2 Nov 2014, at 12:41, Dag-Erling Smørgrav wrote:
>
> Mark R V Murray writes:
>> I’m scared witless of this being on-by-default, for the reason given
>> in the removed comment. I’d much prefer to see it only turned on if a
>> kernel option is set, and the embedded folks /et al/ can use that
Mark R V Murray writes:
> DES’s change makes no difference in a Tier-1 platform, except
> potentially hiding a security problem.
I will assume that you did not read the discussion that lead up to my
commits, because if you did, you know this is a lie.
DES
--
Dag-Erling Smørgrav - d...@des.no
__
Mark R V Murray writes:
> I’m scared witless of this being on-by-default, for the reason given
> in the removed comment. I’d much prefer to see it only turned on if a
> kernel option is set, and the embedded folks /et al/ can use that.
You didn't seem to mind this code when we introduced it in 10
> On 2 Nov 2014, at 09:59, Andrey Chernov wrote:
>
> On 02.11.2014 12:45, Mark R V Murray wrote:
>> Hi DES,
>>
>> I’m scared witless of this being on-by-default, for the reason given in the
>> removed comment. I’d much prefer to see it only turned on if a kernel option
>> is set, and the embe
On 02.11.2014 12:45, Mark R V Murray wrote:
> Hi DES,
>
> I’m scared witless of this being on-by-default, for the reason given in the
> removed comment. I’d much prefer to see it only turned on if a kernel option
> is set, and the embedded folks /et al/ can use that.
We don't need yet one kerne
Hi DES,
I’m scared witless of this being on-by-default, for the reason given in the
removed comment. I’d much prefer to see it only turned on if a kernel option is
set, and the embedded folks /et al/ can use that.
Please reinstate the #ifdef RANDOM_AUTOSEED, and set a kernel option to turn it
> On 2 Nov 2014, at 02:01, Dag-Erling Smørgrav wrote:
>
> Author: des
> Date: Sun Nov 2 02:01:55 2014
> New Revision: 273958
> URL: https://svnweb.freebsd.org/changeset/base/273958
>
> Log:
> Restore the auto-reseed logic, but move it to a much later point,
> immediately before kick_init.
>
Woo, this fixed the embedded boot! Thanks!
-adrian
On 1 November 2014 19:01, Dag-Erling Smørgrav wrote:
> Author: des
> Date: Sun Nov 2 02:01:55 2014
> New Revision: 273958
> URL: https://svnweb.freebsd.org/changeset/base/273958
>
> Log:
> Restore the auto-reseed logic, but move it to a muc
Author: des
Date: Sun Nov 2 02:01:55 2014
New Revision: 273958
URL: https://svnweb.freebsd.org/changeset/base/273958
Log:
Restore the auto-reseed logic, but move it to a much later point,
immediately before kick_init.
Approved by: so (self)
Modified:
head/sys/dev/random/random_adapto
34 matches
Mail list logo
