All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Zhang Yanfei <zhangyanfei.yes@gmail.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: Fri, 24 May 2013 20:01:36 -0700	[thread overview]
Message-ID: <87k3mnahkf.fsf@xmission.com> (raw)
In-Reply-To: <51A006CF.90105@gmail.com> (Zhang Yanfei's message of "Sat, 25 May 2013 08:33:19 +0800")

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.

Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Zhang Yanfei <zhangyanfei.yes@gmail.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: Fri, 24 May 2013 20:01:36 -0700	[thread overview]
Message-ID: <87k3mnahkf.fsf@xmission.com> (raw)
In-Reply-To: <51A006CF.90105@gmail.com> (Zhang Yanfei's message of "Sat, 25 May 2013 08:33:19 +0800")

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.

Eric

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

  reply	other threads:[~2013-05-25  3:02 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
2013-05-25  0:33           ` Zhang Yanfei
2013-05-25  3:01           ` Eric W. Biederman [this message]
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=87k3mnahkf.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=d.hatayama@jp.fujitsu.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 \
    --cc=zhangyanfei.yes@gmail.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.