[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51A2A524.4080303@jp.fujitsu.com>
Date: Mon, 27 May 2013 09:13:24 +0900
From: HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Vivek Goyal <vgoyal@...hat.com>, ebiederm@...ssion.com,
cpw@....com, kumagai-atsushi@....nes.nec.co.jp,
lisa.mitchell@...com, kexec@...ts.infradead.org,
linux-kernel@...r.kernel.org, zhangyanfei@...fujitsu.com,
jingbai.ma@...com, linux-mm@...ck.org, riel@...hat.com,
walken@...gle.com, hughd@...gle.com, kosaki.motohiro@...fujitsu.com
Subject: Re: [PATCH v8 3/9] vmcore: treat memory chunks referenced by PT_LOAD
program header entries in page-size boundary in vmcore_list
(2013/05/24 22:12), Vivek Goyal wrote:
> On Thu, May 23, 2013 at 02:49:28PM -0700, Andrew Morton wrote:
>> On Thu, 23 May 2013 14:25:13 +0900 HATAYAMA Daisuke <d.hatayama@...fujitsu.com> wrote:
>>
>>> Treat memory chunks referenced by PT_LOAD program header entries in
>>> page-size boundary in vmcore_list. Formally, for each range [start,
>>> end], we set up the corresponding vmcore object in vmcore_list to
>>> [rounddown(start, PAGE_SIZE), roundup(end, PAGE_SIZE)].
>>>
>>> This change affects layout of /proc/vmcore.
>>
>> Well, changing a userspace interface is generally unacceptable because
>> it can break existing userspace code.
>>
>> If you think the risk is acceptable then please do explain why. In
>> great detail!
>
> I think it should not be a problem as /proc/vmcore is useful only when
> one parses the elf headers and then accesses the contents of file based
> on the header information. This patch just introduces additional areas
> in /proc/vmcore file and ELF headers still point to right contents. So
> any tool parsing ELF headers and then accessing file contents based on
> that info should still be fine.
>
> AFAIK, no user space tool should be broken there.
>
> Thanks
> Vivek
>
Yes, the changes are new introduction of holes between components of ELF
and tools doesn't reach the holes as long as by looking up program header
table and other tables. cp command touches the holes but trivially works
well.
--
Thanks.
HATAYAMA, Daisuke
--
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