linux-kernel.vger.kernel.org archive mirror
 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 16:31:58 +0800	[thread overview]
Message-ID: <51A076FE.3060604@gmail.com> (raw)
In-Reply-To: <87k3mnahkf.fsf@xmission.com>

于 2013年05月25日 11:01, Eric W. Biederman 写道:
> Zhang Yanfei <zhangyanfei.yes@gmail.com> writes:
> 
>> Hello Eric,
>>
>>> 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.
> 
> Exactly.
> 
> The user space change in /sbin/kexec should even be backwards compatible
> for s390.  So fixing /sbin/kexec should probably come first.
> 

I am kind of not sure about the "backwards compatible for s390" you meant.

For s390, if we put swap info into the elf header, This will change /sbin/kexec.
But at this point, copy_oldmem_page is still doing the swap when we try to read
the pages among [0 - OLDMEM_SIZE] and [OLDMEM_BASE - OLDMEM_BASE + OLDMEM_SIZE].
So removing the swap in copy_oldmem_page should be done at the same time.
New kexec with old kernels would fail and old kexec with new kernels would fail too.

So could you please explain more about the ""backwards compatible". And please
correct me if I am wrong.

Thanks
Zhang



  reply	other threads:[~2013-05-25  8:32 UTC|newest]

Thread overview: 27+ 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 ` [PATCH 1/2] kdump/mmap: Introduce arch_oldmem_remap_pfn_range() 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 14:36 ` [PATCH 0/2] kdump/mmap: Fix mmap of /proc/vmcore " Vivek Goyal
2013-05-24 15:06   ` Michael Holzheu
2013-05-24 15:28     ` Vivek Goyal
2013-05-24 16:46       ` Michael Holzheu
2013-05-24 17:05         ` Vivek Goyal
2013-05-25 13:13           ` Michael Holzheu
2013-05-24 22:44       ` Eric W. Biederman
2013-05-25  0:33         ` Zhang Yanfei
2013-05-25  3:01           ` Eric W. Biederman
2013-05-25  8:31             ` Zhang Yanfei [this message]
2013-05-25 12:52               ` Michael Holzheu
2013-05-28 13:55                 ` Vivek Goyal
2013-05-29 11:51                   ` Michael Holzheu
2013-05-29 16:23                     ` Vivek Goyal
2013-05-29 17:12                       ` Michael Holzheu
2013-05-30 15:00                         ` Vivek Goyal
2013-05-30 20:38                     ` Vivek Goyal
2013-05-31 14:21                       ` Michael Holzheu
2013-05-31 16:01                         ` Vivek Goyal
2013-06-03 13:27                           ` Michael Holzheu
2013-06-03 15:59                             ` Vivek Goyal
2013-06-03 16:48                               ` Michael Holzheu
2013-05-28 14:44                 ` Vivek Goyal
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=51A076FE.3060604@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).