lkml.org 
[lkml]   [2017]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: nios2 crash due to 'init/main.c: extract early boot entropy from the passed cmdline'
On Mon, Sep 11, 2017 at 11:25 AM, Daniel Micay <danielmicay@gmail.com> 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@roeck-us.net>
>> > wrote:
>> > > Hi,
>> > >
>> > > I noticed that nios2 images crash in mainline. Bisect points to
>> > > commit
>> > > 33d72f3822d7 ("init/main.c: extract early boot entropy from the
>> > > passed
>> > > cmdline"). Bisect log is attached.
>> > >
>> > > As far as I can see, the problem is seen because
>> > > add_device_randomness()
>> > > calls random_get_entropy(). However, the underlying timer function
>> > > used by the nios2 architecture (nios2_timer_read) is not yet
>> > > initialized,
>> > > causing a NULL pointer access and crash. A sample crash log is at
>> > > http://kerneltests.org/builders/qemu-nios2-master/builds/1
>> > > 75/steps/qemubuildcommand/logs/stdio
>> >
>> > 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
>> messages.
>> The code path is through get_cycles().
>>
>> On nios2:
>>
>> static u64 nios2_timer_read(struct clocksource *cs)
>> {
>> struct nios2_clocksource *nios2_cs = to_nios2_clksource(cs);
>> unsigned long flags;
>> u32 count;
>>
>> local_irq_save(flags);
>> count = read_timersnapshot(&nios2_cs->timer); // <- not
>> initialized
>> local_irq_restore(flags);
>>
>> /* Counter is counting down */
>> return ~count;
>> }
>>
>> cycles_t get_cycles(void)
>> {
>> return nios2_timer_read(&nios2_cs.cs);
>> }
>> EXPORT_SYMBOL(get_cycles);
>>
>> Guenter
>
> 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
set.

-Kees

--
Kees Cook
Pixel Security

\
 
 \ /
  Last update: 2017-09-11 20:41    [W:0.055 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site