On Sun, Dec 15, 2013 at 05:09:10PM -0500, George Spelvin wrote:
> Well, /dev/urandom is documented as being *deliberately* slow. It's meant
> only to produce 128 to 256 bits of seed material for CPRNG. I don't
> know if Ted considers speeding it up to be goal or an antigoal. :-)
Hmm, I don't thi
On Sat, Dec 14, 2013 at 02:23:07PM -0500, Theodore Ts'o wrote:
> I'm much more inclined to think about changing how we generate random
> numbers from the output pool by switching from using SHA to AES in
> some one-way random function mode (i.e., such as the Davies-Meyer
> construction), since that
particularly helpful in the next commit, where we add
another parameter to account() and extract_entropy().
Signed-off-by: Greg Price
---
drivers/char/random.c | 61 ---
1 file changed, 33 insertions(+), 28 deletions(-)
diff --git a/drivers/cha
andom and the kernel's general use, on
the other hand, should be at least 128 for good commercial security
and users may want it higher.
Make a new parameter for the minimum size of a reseed, and make it
128 by default.
Signed-off-by: Greg Price
---
drivers/char/ran
he current code, as we
don't make repeated small reseeds anyway, but it's best to be clear.
Rename entropy_total to seed_entropy_bits to reflect its new function.
While touching the not-yet-initialized warnings, checkpatch complains
about printk(KERN_NOTICE, ...), so switch to pr_notice
" if someone glimpses the internal state --
which is largely an academic question, given what an attacker who can
read kernel memory is usually able to do. We still take a
regular-sized seed up front so as not to delay getting initialized.
Signed-off-by: Greg Price
-
Until then, we need all the entropy we can get. The "min_bytes"
logic takes care of making these reseeds catastrophic, and
reserving entropy for /dev/random isn't a priority in early boot.
Signed-off-by: Greg Price
---
drivers/char/random.c | 2 +-
1 file changed, 1 insertion
om is seeded is no big deal. This logic still
ensures that /dev/random readers won't starve indefinitely.
At present most input goes directly to the nonblocking pool early on
anyway, but this helps put us in a position to change that.
Signed-off-by: Greg Price
---
drivers/char/ran
s are
interchangeable, but the next commit will make them differ.
Signed-off-by: Greg Price
---
drivers/char/random.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index a624262e8..c11281551 100644
a whole 64-bit reseed while producing
output from virtually no entropy.
At present most input goes directly to the nonblocking pool early on
anyway, but this helps put us in a position to change that.
Signed-off-by: Greg Price
---
drivers/char/random.c | 17 +
1 file changed, 13 i
hat.
This adds a wrinkle to determining when we're ready for someone to
read from /dev/random, so factor that out.
At present most input goes directly to the nonblocking pool early
on anyway, but this puts us in a position to change that.
Signed-off-by: Greg Price
---
drivers/cha
m the computation on nonblocking_pool.
Also compute 'initialized' only for nonblocking_pool, which is the
only place where the concept really makes sense.
Signed-off-by: Greg Price
---
drivers/char/random.c | 17 +
include/trace/events/random.h | 24
accomplished by
sending the input straight to the nonblocking pool early on.
Signed-off-by: Greg Price
---
drivers/char/random.c | 19 ++-
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 58e3e81d4..ea389723f 100644
---
ber estimates allow. The credit_bits output
parameter takes care of that.
Signed-off-by: Greg Price
---
drivers/char/random.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index c11281551..c2428ecb2 100644
--- a/drivers/char/random.c
++
7cd8c30 "random: simplify accounting code"
a few commits ago. Before that, for a long time we would compare
have_bytes - reserved (or equivalent) to ibytes or store it into ibytes,
but only inside a condition that guaranteed it wasn't negative.
Signed-off-by: Greg Price
---
drivers
we make it clear that overflow
isn't an issue. Also we might be less likely to make mistakes like
the one fixed in the previous commit.
As a bonus, give a name to the minimum number of bytes to pull,
which we use twice.
Signed-off-by: Greg Price
---
drivers/char/random.c | 11 +--
1
eds of
doubling size until we reach the target (by default 512b estimated.)
Until we first reach the minimum reseed size (128b by default), all
input collected is exclusively for the nonblocking pool and
/dev/random readers must wait.
Cheers,
Greg
Greg Price (14):
random: fix signedness bug
r
These are a recurring cause of confusion, so rename them to
hopefully be clearer.
Signed-off-by: Greg Price
---
drivers/char/random.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index
The variable 'entropy_bytes' is set from an expression that actually
counts bits. Fortunately it's also only compared to values that also
count bits. Rename it accordingly.
Signed-off-by: Greg Price
---
drivers/char/random.c | 6 +++---
1 file changed, 3 insertions(+), 3 del
names. (Maybe other names should be
clarified too.) This may as well be post-3.13.
Cheers,
Greg
Greg Price (2):
random: entropy_bytes is actually bits
random: clarify bits/bytes in wakeup thresholds
drivers/char/random.c | 36 ++--
1 file changed, 1
On Thu, Dec 05, 2013 at 08:13:47PM -0500, Theodore Ts'o wrote:
> On Wed, Nov 13, 2013 at 03:08:41AM -0500, Greg Price wrote:
> > + if (ibytes && cmpxchg(&r->entropy_count, orig, entropy_count) != orig)
> > + goto retry;
>
> I wonder if we wou
On Fri, Nov 29, 2013 at 03:09:05PM -0500, Theodore Ts'o wrote:
> Applied, although I slightly edited the commit description the the
> debug message mentioned in the description was removed since the first
> version of your patch series, and it wasn't updated as part of the
> rebase.
Ah, good catch
On Sun, Nov 17, 2013 at 06:15:32PM -0800, Joe Perches wrote:
> On Sun, 2013-11-17 at 21:07 -0500, Greg Price wrote:
> > Perhaps the following tweak to the error message would make this
> > subtlety clearer?
>
> Maybe, but this case isn't a macro. It's a function.
g to define a semantics for that gets real ugly real fast.
> sparse matches gcc behaviour (I hope), but it warns about such abuses.
> It's a defect, all right - one being reported by sparse.
Perhaps the following tweak to the error message would make this
subtlety clearer?
Cheers,
Greg
Fro
er we had enough
bits, even though we don't apply it to actually limit how many we
take. The callers of account() never exercise either of these cases.
Before the previous commit, it was possible for "nbytes" to be less
than "min" if userspace chose a pathological configuratio
24 bits, so for now just limit them both.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 1f43f9e..865c8db 100644
--- a/drivers/char/ra
accesses to ->entropy_count here. Drop the use of the lock.
Cc: Jiri Kosina
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 5dffca8..1f43f9e 10
This comment didn't quite keep up as extract_entropy() was split into
four functions. Put each bit by the function it describes.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 31 +--
1 file changed, 21 inserti
s never negative.)
Cc: "Theodore Ts'o"
Cc: Jiri Kosina
Cc: "H. Peter Anvin"
Signed-off-by: Greg Price
---
drivers/char/random.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index fe7ecdd
After this remark was written, commit d2e7c96af added a use of
arch_get_random_long() inside the get_random_bytes codepath.
The main point stands, but it needs to be reworded.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 5 +++--
1 file changed, 3 i
urn directly. Some other simplifications.
The behavior should be identical except that I've changed a debug
message.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 57 ---
1 file changed, 18 insertions(+
There's only one function here now, as uuid_strategy is long gone.
Also make the bit about "If accesses via ..." clearer.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff -
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index cdf4cfb..ed72be5 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@
d one tightens slightly a bound on a sysctl value to avoid a
pathological case.
The bugfix that was in v1 was taken care of by Peter in a283b5c45
("random: allow fractional bits to be tracked").
Cheers,
Greg
Greg Price (9):
random: fix typos / spelling errors in comments
random:
On Wed, Nov 13, 2013 at 01:08:07AM -0500, Theodore Ts'o wrote:
> On Tue, Nov 12, 2013 at 11:23:03PM -0500, Greg Price wrote:
> > That's a good idea. I've worried about the same thing, but hadn't
> > thought of that solution.
>
> I think the key is that w
On Tue, Nov 12, 2013 at 08:51:18PM -0800, H. Peter Anvin wrote:
> On 11/12/2013 08:37 PM, Greg Price wrote:
> > I'm thinking only of boot-time blocking. The idea is that once
> > /dev/urandom is seeded with, say, 128 bits of min-entropy in the
> > absolute, informati
On Tue, Nov 12, 2013 at 08:02:09PM -0800, H. Peter Anvin wrote:
> One thing, too, if we are talking about anything other than
> boot-time-only blocking: going from a nonblocking to a blocking
> condition means being able to accept a short read, and right now *many*
> users of /dev/urandom are not r
On Tue, Nov 12, 2013 at 10:32:05PM -0500, Theodore Ts'o wrote:
> One of the things I've been thinking about with respect to making
> /dev/urandom block is being able to configure (via a module parameter
> which could be specified on the boot command line) which allows us to
> set a limit for how lo
On Mon, Nov 11, 2013 at 11:24:44PM -0500, Theodore Ts'o wrote:
> My apologies for not being able to get to this patch series before the
> patch window opened --- this week has been crazy. None of the changes
> seem to be especially critical, and a number of the patches don't
> apply cleanly to the
Hi Ted,
After reading through the RNG code, I'm curious about one aspect and I
wonder if you can shed light on it. Since v3.6-rc1~26^2~30 ("random:
use lockless techniques in the interrupt path"), we mix bytes into the
pool without taking the lock, when inside add_interrupt_randomness().
This mea
and zero bytes is zero bits.
Cc: "Theodore Ts'o"
Cc: Jiri Kosina
Signed-off-by: Greg Price
---
drivers/char/random.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 8824e8d..9e4645e 100644
--- a/drivers/cha
This commit makes the very boring simplifications so that the next
commit, which is a little trickier, is isolated and easy to review.
No change in behavior here at all.
Cc: "Theodore Ts'o"
Cc: Jiri Kosina
Signed-off-by: Greg Price
---
drivers/char/random.c | 10 --
1
er we had enough
bits, even though we don't apply it to actually limit how many we
take. The callers of account() never exercise either of these cases.
Cc: "Theodore Ts'o"
Cc: Jiri Kosina
Signed-off-by: Greg Price
---
drivers/char/random.c | 23 ---
1 file ch
urn directly. Some other simplifications.
The behavior should be identical except that I've changed a debug
message.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 68 +--
1 file changed, 22 insertions(+
After this remark was written, commit d2e7c96af added a use of
arch_get_random_long() inside the get_random_bytes codepath.
The main point stands, but it needs to be reworded.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 5 +++--
1 file changed, 3 i
This comment didn't quite keep up as extract_entropy() was split into
four functions. Put each bit by the function it describes.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 31 +--
1 file changed, 21 inserti
We cheerfully overflow these variables (at least where "int"
is 32 bits wide), so pedantically they should be unsigned.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
ropy_count / 8 - reserved bytes from the pool,
even though this is less than min.
Move the "min" check inside the ACCESS_ONCE/cmpxchg loop to
prevent the race.
Cc: Jiri Kosina
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 9 -
1
accesses to ->entropy_count here. Drop the use of the lock.
Cc: Jiri Kosina
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9e4645e..1bf6bf8 10
There's only one function here now, as uuid_strategy is long gone.
Also make the bit about "If accesses via ..." clearer.
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff -
ivial signedness fix. Two patches change the locking
and lockless concurrency control in account(), including one bugfix.
The bug is related to the one Jiri found and fixed in May.
Cheers,
Greg
Greg Price (11):
random: fix typos / spelling errors in comments
random: fix comment on proc_do_uuid
r
Cc: "Theodore Ts'o"
Signed-off-by: Greg Price
---
drivers/char/random.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 7a744d3..ef3e15b 100644
--- a/drivers/char/random.c
+++ b/drivers/char/rand
Commit-ID: b21484f1a1f300d422cfe5d4f8f50015e22cea24
Gitweb: http://git.kernel.org/tip/b21484f1a1f300d422cfe5d4f8f50015e22cea24
Author: Greg Price
AuthorDate: Thu, 6 Dec 2012 21:48:05 -0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Fri, 12 Jul 2013 13:53:55 -0300
perf report/top
On Mon, Jul 08, 2013 at 03:10:52PM +0200, Jiri Olsa wrote:
> On Mon, Jul 08, 2013 at 08:11:50AM -0400, Greg Price wrote:
> > We use these macros in a few files in ui/gtk/ and they work fine
> > because GTK includes GLib which defines them, but here in util/
> > they break the
We use these macros in a few files in ui/gtk/ and they work fine
because GTK includes GLib which defines them, but here in util/
they break the build, at least on my machine. So stick to 0 and 1.
Cc: Arnaldo Carvalho de Melo
Cc: Waiman Long
Cc: Jiri Olsa
Signed-off-by: Greg Price
---
This
On Sun, Jul 07, 2013 at 03:13:40PM +0200, Jiri Olsa wrote:
> On Mon, Jul 01, 2013 at 10:28:45AM -0400, Greg Price wrote:
> > For example, in an application with an expensive function
> > implemented with deeply nested recursive calls, the default
> > call-graph presentatio
Signed-off-by: Greg Price
---
Now on top of v3.10. Option renamed, added to top, comment and doc added.
tools/perf/Documentation/perf-report.txt | 5 +
tools/perf/Documentation/perf-top.txt| 5 +
tools/perf/builtin-report.c | 27 ---
tool
stra
Cc: Ingo Molnar
Signed-off-by: Greg Price
---
The relevant previous thread:
On Thu, Jun 27, 2013 at 01:58:16PM +0900, Namhyung Kim wrote:
> On Wed, 26 Jun 2013 18:25:01 -0400, Greg Price wrote:
> > On Wed, Jun 26, 2013 at 10:28:56AM +0900, Namhyung Kim wrote:
> &
On Thu, Jun 27, 2013 at 01:58:16PM +0900, Namhyung Kim wrote:
> On Wed, 26 Jun 2013 18:25:01 -0400, Greg Price wrote:
> > On Wed, Jun 26, 2013 at 10:28:56AM +0900, Namhyung Kim wrote:
> >> On Sat, 22 Jun 2013 23:17:20 -0400, Greg Price wrote:
> >> > @@
Hi Namhyung, hi Ingo,
On Tue, Jun 25, 2013 at 05:01:47PM +0900, Namhyung Kim wrote:
> >>TBH I'm not really familiar with the GTK front-end, as I mainly use
> >>the TUI. At a quick trial, it looks like --blackbox has the expected
> >>effect on the display there; though with or without --blackbox I
Hi Namhyung,
Thanks for the detailed review!
On Wed, Jun 26, 2013 at 10:28:56AM +0900, Namhyung Kim wrote:
> On Sat, 22 Jun 2013 23:17:20 -0400, Greg Price wrote:
> > For example, in an application with an expensive function
> > implemented with deeply nested recursive cal
On Mon, Jun 24, 2013 at 10:32:53AM +0200, Ingo Molnar wrote:
> * Jiri Olsa wrote:
> > It could also make sense to allow sorting on this
> > the same way as we do for '-s parent' and report only
> > '[other]' and 'blackbox' entries.
> >
> > Also I dont like the 'blackbox' option name, it should
>
On Sun, Jun 23, 2013 at 11:53:27PM +0200, Jiri Olsa wrote:
> Seems useful, sort of oposite to parent option (-p)
Cool, good to hear.
> Any reason why not add this for top?
Only because I didn't think about it. :) Seems like a good idea; I'll
add that.
> > diff --git a/tools/perf/util/machine
eature
| | rb_require_safe
| | vm_call_method
Cc: Arnaldo Carvalho de Melo
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: David Ahern
Signed-off-by: Greg Price
---
On Fri, Jan 11, 2013 at 02:27:36AM -0300, Arnaldo Carvalho d
On Fri, Jan 11, 2013 at 02:27:36AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Dec 07, 2012 at 02:30:44AM -0500, Greg Price escreveu:
> > If an application has an expensive function implemented with a large
> > tree of calls to helper functions, the default call-graph presentat
eature
| | rb_require_safe
| | vm_call_method
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: David Ahern
Signed-off-by: Greg Price
---
tools/perf/builtin-report.c | 17 +++--
66 matches
Mail list logo
