On Mon, Sep 11, 2017 at 11:25 AM, Daniel Micay <danielmicay@xxxxxxxxx> wrote:
On Mon, 2017-09-11 at 10:35 -0700, Guenter Roeck wrote:
On Mon, Sep 11, 2017 at 09:36:00AM -0700, Kees Cook wrote:
On Sat, Sep 9, 2017 at 8:58 PM, Guenter Roeck <linux@xxxxxxxxxxxx>
I noticed that nios2 images crash in mainline. Bisect points to
33d72f3822d7 ("init/main.c: extract early boot entropy from the
cmdline"). Bisect log is attached.
As far as I can see, the problem is seen because
calls random_get_entropy(). However, the underlying timer function
used by the nios2 architecture (nios2_timer_read) is not yet
causing a NULL pointer access and crash. A sample crash log is at
Oh, yikes. Do you have a full call trace? (Does this come through
get_cycles() or via the It seems like we could either initialize the
timer earlier or allow it to fall back when not initialized...
nios2 doesn't give me a traceback. I followed it by adding debug
The code path is through get_cycles().
static u64 nios2_timer_read(struct clocksource *cs)
struct nios2_clocksource *nios2_cs = to_nios2_clksource(cs);
unsigned long flags;
count = read_timersnapshot(&nios2_cs->timer); // <- not
/* Counter is counting down */
Maybe it should WARN and return 0 for now if that's NULL?
In this case, we'd always WARN. :P But yeah, 0 return on NULL timer
seems okay to me here. I am curious if it's possible to start the
timer earlier, though. It's not clear to me where nios2_cs->timer gets