On 2013/12/03 18:06:13, kexec <kexec-boun...@lists.infradead.org> wrote: > >> This is a suggestion from different point of view... > >> > >> In general, data on crash dump can be corrupted. Thus, order contained in > >> a page > >> descriptor can also be corrupted. For example, if the corrupted value were > >> a huge > >> number, wide range of pages after buddy page would be filtered falsely. > >> > >> So, actually we should sanity check data in crash dump before using them > >> for application > >> level feature. I've picked up order contained in page descriptor, so there > >> would be other > >> data used in makedumpfile that are not checked. > > > > What you said is reasonable, but how will you do such sanity check ? > > Certain standard values are necessary for sanity check, how will > > you prepare such values ? > > (Get them from kernel source and hard-code them in makedumpfile ?) > > > >> Unlike diskdump, we no longer need to care about kernel/hardware level > >> data integrity > >> outside of user-land, but we still care about data its own integrity. > >> > >> On the other hand, if we do it, we might face some difficulty, for > >> example, hardness of > >> maintenance or performance bottleneck; it might be the reason why we don't > >> see sanity > >> check in makedumpfile now. > > > > There are many values which should be checked, e.g. page.flags, page._count, > > page.mapping, list_head.next and so on. > > If we introduce sanity check for them, the issues you mentioned will be > > appear > > distinctly. > > > > So I think makedumpfile has to trust crash dump in practice. > > > > Yes, I don't mean such very drastic checking; I understand hardness because I > often > handle/write this kind of code; I don't want to fight tremendously many > dependencies... > > So we need to concentrate on things that can affect makedumpfile's behavior > significantly, > e.g. infinite loop caused by broken linked list objects, buffer overrun > cauesd by large values > from broken data, etc. We should be able to deal with them by carefully > handling > dump data against makedumpfile's runtime data structure, e.g., buffer size. > > Is it OK to consider this is a policy of makedumpfile for data corruption?
Right. Of course, if there is a very simple and effective check for a dump data, then we can take it. Thanks Atsushi Kumagai > -- > Thanks. > HATAYAMA, Daisuke > > > _______________________________________________ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
