All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhang Yanfei <zhangyanfei.yes@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>,
	Michael Holzheu <holzheu@linux.vnet.ibm.com>,
	HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	Jan Willeke <willeke@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390
Date: Sat, 25 May 2013 08:33:19 +0800	[thread overview]
Message-ID: <51A006CF.90105@gmail.com> (raw)
In-Reply-To: <87mwrkatgu.fsf@xmission.com>

Hello Eric,

于 2013年05月25日 06:44, Eric W. Biederman 写道:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
>> On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
>>> Hello Vivek,
>>>
>>> On Fri, 24 May 2013 10:36:44 -0400
>>> Vivek Goyal <vgoyal@redhat.com> wrote:
>>>
>>> [snip]
>>>
>>>> Sorry, I don't understand the problem. If we swapped low memory and
>>>> crash reserved memory, that should have been taken care by prepared
>>>> ELF headers so that we map the right pfns. In x86 we swap 640K of low
>>>> memory with 640K of memory in reserved and we take care of this by
>>>> preparing elf headers accordingly.
>>>>
>>>> So why s390 can't do the same thing?
>>>
>>> I am not sure if I understand this. Currently we create the ELF
>>> header in a way that we have virtual=real. In the copy_oldmem_page() we
>>> do the swap so that for the /proc/vmcore code it looks like contiguous
>>> non-swapped memory.
>>>
>>> One reason why I thought this was necessary was that /dev/oldmem
>>> also uses the function and it should provide linear memory access like
>>> it is on the live system with /dev/mem.
>>>
>>> Is that implementation incorrect?
>>
>> [ CC Andrew. Keep him in loop for all kernel kdump patches as all kdump
>>   patches are routed through him ].
>>
>> [ CC Eric Biederman ]
>>
>> Looking at the code, looks like /dev/oldmem is broken. It does not know
>> anything about swap of any of the memory areas and it will simply
>> return the contents of page frame asked. And this has been like this
>> since the beginning.
>>
>> I have always questioned the utility of /dev/oldmem. Atleast I am not
>> aware of any tool making use of it.
>>
>> If we want to fix it, then somebow all the swapped memory region info
>> needs to be communicated to second kernel so that read_oldmem() can
>> do the mapping correctly and we really don't have any mechanism for
>> that. (I am assuming that in s390 you must have hardcoded the regions
>> of memory which are always swapped).
>>
>> As /proc/vmcore is the most used and useful interface, I prefer that
>> we swap memory and put that info in elf headers. For /dev/oldme, I
>> don't mind if we leave it as it is. If somebody really cares, then
>> I guess we need to write a new command line option which /dev/mem
>> can parse and which tells it about swaps so that /dev/oldmem can
>> map things correctly. (This is better than hardcoding things).
>>
>> Eric, do you have any thoughts on this.
> 
> I don't think anyone actually uses /dev/oldmem.  I would like to cite
> the s390 confusion as proof but I don't think that quite works.
> 
> I think the solution is for someone to send a patch removing /dev/oldmem
> as an unused piece of code.  That will also move us in the direction of
> resolving HPAs concerns.

I think I can try this.

> 
> The function copy_oldmem_page also concerns me.  I don't have a clue why
> we duplicate that function on every architecutre in a slightly different
> form.  There should be enough abstractions in the kernel to make that
> unnecessary.  I would be glad to see that function go, and remove the
> possibility of confusion that happened on s390.

You mean we should have a common copy_oldmem_page for all architectures? And
just like vivek said above, for s390, we should put the swap info in the elf
headers instead of doing that in copy_oldmem_page.

Zhang

WARNING: multiple messages have this Message-ID (diff)
From: Zhang Yanfei <zhangyanfei.yes@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: kexec@lists.infradead.org,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Jan Willeke <willeke@de.ibm.com>,
	linux-kernel@vger.kernel.org,
	HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michael Holzheu <holzheu@linux.vnet.ibm.com>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390
Date: Sat, 25 May 2013 08:33:19 +0800	[thread overview]
Message-ID: <51A006CF.90105@gmail.com> (raw)
In-Reply-To: <87mwrkatgu.fsf@xmission.com>

Hello Eric,

于 2013年05月25日 06:44, Eric W. Biederman 写道:
> Vivek Goyal <vgoyal@redhat.com> writes:
> 
>> On Fri, May 24, 2013 at 05:06:26PM +0200, Michael Holzheu wrote:
>>> Hello Vivek,
>>>
>>> On Fri, 24 May 2013 10:36:44 -0400
>>> Vivek Goyal <vgoyal@redhat.com> wrote:
>>>
>>> [snip]
>>>
>>>> Sorry, I don't understand the problem. If we swapped low memory and
>>>> crash reserved memory, that should have been taken care by prepared
>>>> ELF headers so that we map the right pfns. In x86 we swap 640K of low
>>>> memory with 640K of memory in reserved and we take care of this by
>>>> preparing elf headers accordingly.
>>>>
>>>> So why s390 can't do the same thing?
>>>
>>> I am not sure if I understand this. Currently we create the ELF
>>> header in a way that we have virtual=real. In the copy_oldmem_page() we
>>> do the swap so that for the /proc/vmcore code it looks like contiguous
>>> non-swapped memory.
>>>
>>> One reason why I thought this was necessary was that /dev/oldmem
>>> also uses the function and it should provide linear memory access like
>>> it is on the live system with /dev/mem.
>>>
>>> Is that implementation incorrect?
>>
>> [ CC Andrew. Keep him in loop for all kernel kdump patches as all kdump
>>   patches are routed through him ].
>>
>> [ CC Eric Biederman ]
>>
>> Looking at the code, looks like /dev/oldmem is broken. It does not know
>> anything about swap of any of the memory areas and it will simply
>> return the contents of page frame asked. And this has been like this
>> since the beginning.
>>
>> I have always questioned the utility of /dev/oldmem. Atleast I am not
>> aware of any tool making use of it.
>>
>> If we want to fix it, then somebow all the swapped memory region info
>> needs to be communicated to second kernel so that read_oldmem() can
>> do the mapping correctly and we really don't have any mechanism for
>> that. (I am assuming that in s390 you must have hardcoded the regions
>> of memory which are always swapped).
>>
>> As /proc/vmcore is the most used and useful interface, I prefer that
>> we swap memory and put that info in elf headers. For /dev/oldme, I
>> don't mind if we leave it as it is. If somebody really cares, then
>> I guess we need to write a new command line option which /dev/mem
>> can parse and which tells it about swaps so that /dev/oldmem can
>> map things correctly. (This is better than hardcoding things).
>>
>> Eric, do you have any thoughts on this.
> 
> I don't think anyone actually uses /dev/oldmem.  I would like to cite
> the s390 confusion as proof but I don't think that quite works.
> 
> I think the solution is for someone to send a patch removing /dev/oldmem
> as an unused piece of code.  That will also move us in the direction of
> resolving HPAs concerns.

I think I can try this.

> 
> The function copy_oldmem_page also concerns me.  I don't have a clue why
> we duplicate that function on every architecutre in a slightly different
> form.  There should be enough abstractions in the kernel to make that
> unnecessary.  I would be glad to see that function go, and remove the
> possibility of confusion that happened on s390.

You mean we should have a common copy_oldmem_page for all architectures? And
just like vivek said above, for s390, we should put the swap info in the elf
headers instead of doing that in copy_oldmem_page.

Zhang

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2013-05-25  0:33 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-24 13:08 [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore for s390 Michael Holzheu
2013-05-24 13:08 ` Michael Holzheu
2013-05-24 13:08 ` [PATCH 1/2] kdump/mmap: Introduce arch_oldmem_remap_pfn_range() Michael Holzheu
2013-05-24 13:08   ` Michael Holzheu
2013-05-24 13:08 ` [PATCH 2/2] s390/kdump/mmap: Implement arch_oldmem_remap_pfn_range() for s390 Michael Holzheu
2013-05-24 13:08   ` Michael Holzheu
2013-05-24 14:36 ` [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore " Vivek Goyal
2013-05-24 14:36   ` Vivek Goyal
2013-05-24 15:06   ` Michael Holzheu
2013-05-24 15:06     ` Michael Holzheu
2013-05-24 15:28     ` Vivek Goyal
2013-05-24 15:28       ` Vivek Goyal
2013-05-24 16:46       ` Michael Holzheu
2013-05-24 16:46         ` Michael Holzheu
2013-05-24 17:05         ` Vivek Goyal
2013-05-24 17:05           ` Vivek Goyal
2013-05-25 13:13           ` Michael Holzheu
2013-05-25 13:13             ` Michael Holzheu
2013-05-24 22:44       ` Eric W. Biederman
2013-05-24 22:44         ` Eric W. Biederman
2013-05-25  0:33         ` Zhang Yanfei [this message]
2013-05-25  0:33           ` Zhang Yanfei
2013-05-25  3:01           ` Eric W. Biederman
2013-05-25  3:01             ` Eric W. Biederman
2013-05-25  8:31             ` Zhang Yanfei
2013-05-25  8:31               ` Zhang Yanfei
2013-05-25 12:52               ` Michael Holzheu
2013-05-25 12:52                 ` Michael Holzheu
2013-05-28 13:55                 ` Vivek Goyal
2013-05-28 13:55                   ` Vivek Goyal
2013-05-29 11:51                   ` Michael Holzheu
2013-05-29 11:51                     ` Michael Holzheu
2013-05-29 16:23                     ` Vivek Goyal
2013-05-29 16:23                       ` Vivek Goyal
2013-05-29 17:12                       ` Michael Holzheu
2013-05-29 17:12                         ` Michael Holzheu
2013-05-30 15:00                         ` Vivek Goyal
2013-05-30 15:00                           ` Vivek Goyal
2013-05-30 20:38                     ` Vivek Goyal
2013-05-30 20:38                       ` Vivek Goyal
2013-05-31 14:21                       ` Michael Holzheu
2013-05-31 14:21                         ` Michael Holzheu
2013-05-31 16:01                         ` Vivek Goyal
2013-05-31 16:01                           ` Vivek Goyal
2013-06-03 13:27                           ` Michael Holzheu
2013-06-03 13:27                             ` Michael Holzheu
2013-06-03 15:59                             ` Vivek Goyal
2013-06-03 15:59                               ` Vivek Goyal
2013-06-03 16:48                               ` Michael Holzheu
2013-06-03 16:48                                 ` Michael Holzheu
2013-05-28 14:44                 ` Vivek Goyal
2013-05-28 14:44                   ` Vivek Goyal
2013-05-25 20:36               ` Eric W. Biederman
2013-05-25 20:36                 ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51A006CF.90105@gmail.com \
    --to=zhangyanfei.yes@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=ebiederm@xmission.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=holzheu@linux.vnet.ibm.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=vgoyal@redhat.com \
    --cc=willeke@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.