[Crash-utility] Re: nr_cpus is not calculated properly

[Dave Anderson]

----- "Bernhard Walle" <bernhard.walle at gmx.de> wrote:

> Dave Anderson schrieb:
> >>
> >> As we know, on x86(32 bits), uint32_t is 4 bytes and uint64_t is 8
> >> bytes. 
> >>
> >> So this line
> >>    140          nr_cpus = (hdr_size - offset) / sizeof(dump_CPU_info_t);
> >>
> >> would not get a correct nr_cpus due to the sizeof().
> >>
> >> A patch to fix this problem as below.
> > 
> > BTW, what exactly are the ramifications without the patch -- does the
> > crash session die during initialization?  How come nobody ran into 
> > this issue given that the code has been in place for almost 2 years?
>  
> > 
> > 4.0-4.8  - ... 
> > 
> >          - Change for support of LKCD dumpfile version 8 and later to determine
> >            the backtrace starting registers from the dumpfile header.  Increase
> >            (maximum) NR_CPUS for ia64 to 4096.
> >            (bwalle at suse.de)
> > 
> >            ...
> > 
> >            (10/30/07)
> > 
> > Anyway, the patch looks reasonable to me, but I don't touch the LKCD
> > code without a sign-off from the LKCD maintainers on this mailing list.
> > 
> > LKCD maintainers -- do you have any objection to this patch?
> 
> Sorry for that mistake, it was me. :-(
> 
> It's a copy & paste error (the members are just copied from the
> dump_header_asm_t definition above. And I acknowledge the patch (from
> reading it, I have no test material here any more). Troy may give the
> ultimate acknowledge. ;-)
> 
> Regards,
> Bernhard

Good, thanks Bernhard -- it looked pretty obvious, and I'll put it in.  

I still wish the guy had indicated exactly what the failure mode was.

It looks like, at a minimum, there could be one or two LKCD-specific
warning messages during initialization, but the crash session should
still come up, right?  Given that "nr_cpus" is a local variable and
has nothing to do with crash utility's determination of how many cpus 
there are, I wonder what other problems might arise? 

Dave