On 27/05/2016:03:43:33 PM, AKASHI Takahiro wrote:
> On Fri, May 27, 2016 at 10:37:38AM +0530, Pratyush Anand wrote:
> > On 27/05/2016:01:03:56 PM, AKASHI Takahiro wrote:
> > > On Thu, May 26, 2016 at 03:09:55PM +0530, Pratyush Anand wrote:
> > > > On 26/05/2016:05:13:30 PM, AKASHI Takahiro wrote:
> > > > > On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
> > > >
> > > > [...]
> > > >
> > > > > > > (This is the reason that I don't think we need a VMCOREINFO for
> > > > > > > CONFIG_RANDOMIZE_BASE.)
> > > > > >
> > > > > > Well, as long as there's a way to avoid that unnecessary/confusing
> > > > > > warning message for non-KASLR new-vmemmap kernels.
> > > > > >
> > > > > > I also wonder whether makedumpfile could use it?
> > > > >
> > > > > -> Pratyush?
> > > >
> > > > Since second kernel's initrd cannot include a large file like VMLINUX, so
> > > > makedumpfile should also work without passing '-x vmlinux'. Therefore,
> > > > makedumpfile will need some minimal symbol's values to be passed in vmcore.
> > >
> > > I understand.
> > > (but I wonder why makedumpfile doesn't utilize System.map nor .config.)
> >
> > So far makedumpfile has been designed to work only with vmcore as input in it's
> > minimal form (specially in second kernel).
> > +Atsushi & makedumpfile list: He will have better idea about it.
> >
> > Moreover, there are few variables, whose values are needed in order to translate
> > phys to virt and vice versa. So, passing their symbol address would not be of
> > much help. For example, we need to know value of kimage_voffset for __pa(), and
> > so symbol address of kimage_voffset will not help.
>
> I do agree to adding any vmcoreinfo *if* it is really needed,
> and so I'm asking why you need it.
>
> What I'm thinking now is that I would add a minimal set of vmcoreinfo
> which are necessary for crash util to work (for /proc/vmcore, not a live
> system) and then, if you want to add anything else, you can post your
> own patch.
>
> Make sense?
Yes, No issue.
In fact, I do not have any plan to send arm64 makedulpfile enhancement either
until kernel support is upstreamed.
>
> But I think ...
> If we would eventually add, say, "NUMBER(va_bits)", makedumpfile() will
> use it, but crash util doen't. Looks a bit odd.
> -> Dave, do you have any opinion here?
>
> > >
> > > > IIUC, then you need to pass CONFIG_RANDOMIZE_BASE in order to calculate
> > > > PHYS_OFFSET. If yes, then why not to pass PHYS_OFFSET itself into vmcore.
> > >
> > > No, as I said in the discussions, I don't think that we need
> > > CONFIG_RANDOMIZE_BASE *if* we can read a kernel symbol's value
> > > from /proc/vmcore.
> >
> > What I understand that, we can read only those symbols/variables from vmcore
> > which have been embedded using VMCOREINFO_xxxx macros (if we do not pass
> > vmlinux, like in second kernel). Atsushi, please correct me if I am wrong.
> >
> > >
> > > > Following numbers in vmcore [1] is helping me out in implementing __pa() and
> > > > __va() for all page table sizes and levels.
> > > >
> > > > VMCOREINFO_NUMBER(pgtable_levels);
> > > > VMCOREINFO_NUMBER(va_bits);
> > > > VMCOREINFO_NUMBER(page_shift);
> > >
> > > Since We already have VMCOREINFO(PAGESIZE), we won't nedd page_shift.
> >
> > Yes, agreed.
> >
> > > As well, pgtable_levels can be determined by va_bits and PAGESIZE.
> > > See arch/arm64/Kconfig.
> >
> > Yes, agreed.
> >
> > >
> > > > VMCOREINFO_NUMBER(phys_offset);
> > > > VMCOREINFO_NUMBER(config_kasan);
> > >
> > > Let me ask some questions.
> > > * What kind of data in vmcore and how does makedumpfile access
> > > without vmlinux nor System.map?
> >
> > Well, I do not have the deep idea, again Atsushi can help here.
> >
> > makedumpfile mainly compresses vmcore (ram image of panicked kernel),
> > additionally it also excludes unnecessary pages for analysis. It will need
> > symbol information to exclude unnecessary pages, where vmlinux is needed mainly.
> > So, normally we do not perform erase(exclude) functionality in second kernel. It
> > is being performed latter, on a compressed dumpfile.
>
> Well, I don't look into the makedumpfile code in details, it only accesses
> MMU tables and struct page data. So you need a few *well-known* symbols'
> values in vmcore.
>
> > > * Why do you need CONFIG_KASAN?
> >
> > KASAN_SHADOW_SIZE is dependent on CONFIG_KASAN.
> > MODULES_VADDR is dependent on KASAN_SHADOW_SIZE.
> >
> > We need MODULES_VADDR,VMALLOC_START,VMEMMAP_START and their END addresses in
> > order to define whether a virtual to physical translation can be obtained using
> > linear mapping or need to read from page table instead.
>
> I guess that we can check for this simply like:
> vaddr >= PAGE_OFFSET || ("_text" <= vaddr < "_end")
> (Again, *if* we can access kernel symbols' values.)
Unfortunately, We have _stext in vmcore but we do not have _text and _end.
However, instead of passing CONFIG_KASAN and then calculating module, vmalloc
and vmemmap areas in makedumpfile, it would be cleaner to pass _text and _end.
Then, makedumpfile will be immune to changes in kernel for memory layout of
these spaces.
~Pratyush
>
> Thanks,
> -Takahiro AKASHI
>
> > Thanks for the questions and inputs. Those are helpful. :-)
> > ~Pratyush
> > >
> > > Thanks,
> > > -Takahiro AKASHI
> > >
> > > > VMCOREINFO_NUMBER(kimage_voffset);
> > > >
> > > > ~Pratyush
> > > >
> > > > [1]
> > > > https://github.com/pratyushanand/linux/blob/7011e478aae3e568cc8dca15b6c128fe728416f7/arch/arm64/kernel/machine_kexec.c#L275
> > > >
> > > > --
> > > > Crash-utility mailing list
> > > > Crash-utility@xxxxxxxxxx
> > > > https://www.redhat.com/mailman/listinfo/crash-utility
> > >
> > > --
> > > Thanks,
> > > -Takahiro AKASHI
> > >
> > > --
> > > Crash-utility mailing list
> > > Crash-utility@xxxxxxxxxx
> > > https://www.redhat.com/mailman/listinfo/crash-utility
>
> --
> Thanks,
> -Takahiro AKASHI
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
