[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130321143656.GG3934@redhat.com>
Date: Thu, 21 Mar 2013 10:36:56 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: HATAYAMA Daisuke <d.hatayama@...fujitsu.com>, cpw@....com,
kumagai-atsushi@....nes.nec.co.jp, lisa.mitchell@...com,
heiko.carstens@...ibm.com, akpm@...ux-foundation.org,
kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
zhangyanfei@...fujitsu.com
Subject: Re: [PATCH v3 17/21] vmcore: check NT_VMCORE_PAD as a mark
indicating the end of ELF note buffer
On Wed, Mar 20, 2013 at 08:54:25PM -0700, Eric W. Biederman wrote:
[..]
> > Also, it's possible to get size of a whole part of ELF note segments
> > from p_memsz or p_filesz, and gdb and binutils are reading the note
> > segments until reaching the size.
>
> Agreed. Except in our weird case where we generate the notes on the
> fly, and generate the NOTE segment header much earlier.
And in our case we don't know the size of ELF note. Kernel is not
exporting the size. So kexec-tools is putting an upper limit of 1024
and putting that value in p_memsz and p_filesz fields.
Given the fact that we are reserving elf notes at boot. That means
we know the size of ELF notes. It should make sense to export it
to user space and let kexec-tools put right values.
In fact looks like /sys/kernel/vmcoreinfo is exporting two values. Address
and size. (This is kind of violation of sysfs poilcy of one value per
file). But for per cpu notes, we are exporting only address and not
size.
/sys/devices/system/cpu/cpu<n>/crash_notes
May be we should export another file
/sys/devices/system/cpu/cpu<n>/crash_notes_size
and let kexec-tools parse it.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists