On 02/03/2014 08:47 AM, Vivek Goyal wrote: > On Sun, Feb 02, 2014 at 02:25:25PM -0800, Eric W. Biederman wrote: >> Andrew Morton <a...@linux-foundation.org> writes: >> >>> On Sat, 1 Feb 2014 01:07:29 +0000 "Pearson, Greg" <greg.pear...@hp.com> >>> wrote: >>> >>>> As far as I know the only consequence of dropping a PT_NOTE entry is >>>> that it would not be available in the crash dump for use in debugging. >>>> I'm not sure how important this data might be for triage. I'm guessing >>>> that in cases where one of these strange PT_NOTE entries shows up with a >>>> size that causes an overflow it probably isn't even a real PT_NOTE entry >>>> so dropping it won't matter, but that's a guess at this point since I'm >>>> still trying to figure out how the bogus entries were created. >>> Can we detect the crazy-huge notes, skip them and then proceed with >>> the following sanely-sized ones? >> The only way we can have following sanely-sized notes is if they are in >> a separate note segment (one of our extensions for kdump and >> /proc/vmcore merges them together). > This processing is happening before we have merged ELF notes. Previous > kernel/kexec-tools prepared per cpu PT_NOTE type ELF note. One for > each cpu. And by default it prepares only one ELF note per PT_NOTE. So > there should not be more notes in the same PT_NOTE. > > Also even if there are, n_namesz and n_descsz values seem so high that > after skipping these nothing valid should be after that. > > So I will not be too worried about skipping seemingly corrupted ELf > notes. I think giving a warning makes sense though. Is somebody > overwriting the memory area in kenrel reserved for per cpu PT_NOTE.
I haven't figured out the cause of the strange second PT_NOTE entries yet, but I suspect some type of memory corruption. I'll re-cut the patch and add a pr_warn() when we drop an entry. -- Greg > > Thanks > Vivek -- 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/