public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	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
Subject: Re: [PATCH v7 0/5] kdump: Allow ELF header creation in new kernel
Date: Wed, 17 Jul 2013 17:42:07 -0400	[thread overview]
Message-ID: <20130717214207.GB27633@redhat.com> (raw)
In-Reply-To: <20130717180049.3b9c6ec8@holzheu>

On Wed, Jul 17, 2013 at 06:00:49PM +0200, Michael Holzheu wrote:
> > On Tue, Jul 16, 2013 at 06:18:10PM +0200, Michael Holzheu wrote:
> > > Hello Andrew,
> > >
> > > Here a new kdump patch series that we have discussed with Vivek and
> > > Hatayama during the last months.
> > >
> > > Besides of the feature described below, this patch series also fixes a
> > > regression on s390 that was introduced with the mmap patches for
> > > /proc/vmcore (git commit 83086978c63afd7c73e1c).
> > >
> > > See also:
> > > http://lists.infradead.org/pipermail/kexec/2013-July/009287.html
> > >
> > > Is it somehow possible to integrate this patch series into 3.11?
> > 
> > Hi Andrew,
> > 
> > Now /proc/vmcore mmap() patches are in but looks like they will break
> > s390 kdump. mmap() patches use vmalloc() to allocate memory for elf
> > notes and then use read_from_oldmem() to copy notes data from old
> > memory to this newly allocated buffer. read_from_oldmem() in turn
> > uses arch dependent copy_from_oldmem() function.
> > 
> > Look like on s390, copy_from_oldmem() can not copy data to vmalloc()
> > space as they drop to real mode.
> > 
> > As allocating elf notes code is common both for mmap() and read() path,
> > it will break kdump on s390.
> > 
> > Michael has done some cleanups to cope with that but in the process
> > he has also stuffed in the support for zfcpdump and how to deal with
> > HSA region etc. (I am not very happy about it though now. s390 seems
> > to be having so may special case modes and swap logic etc that it
> > is becoming hard to keep track what they are doing. I wished s390
> > first did some cleanup w.r.t swap logic and deal with mmap() in pure
> > kdump mode and then worry about taking care of zfcpdump).
> > 
> > Is it possible to push this series in 3.11 now? I suspect it is late now.
> > Otherwise we might have to revert mmap() patches as in current form
> > they will break s390 kdump.
> > 
> > Michael, Hatayama, in case this series can't go in 3.11, do you have other
> > ideas where a small hack fix will allow kdump to work on s390 and we
> > don't have to revert the mmap() patches.
> 
> Sure, we can somehow change the copy_from_oldmem() function that it
> can copy to virtual memory. We have already discussed some options
> on how to do that. Not nice but probably doable.
> 
> And we could either disable mmap for s390 by removing mmap_vmcore()
> from the proc_vmcore_operations or push the also already discussed
> ELF header swap trick in 3.11.
> 
> But this is all additional effort now and would not be necessary if we
> integrate this patch series in 3.11.
> 
> Perhaps we should let Andrew decide here.

Hi Michael,

Given the fact that andrew too prefers a fix to get s390 working at this
stage can we modify s390 copy_from_oldmem() to be able to copy to 
vmalloc() memory area.

For mmap(), let us disable it on s390. And rest of the cleanups w.r.t
ELF header swap etc, let us now target that for 3.12.

Sounds reasonable?

Thanks
Vivek

  reply	other threads:[~2013-07-17 21:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <OF6010D9F0.5A45F2CF-ONC1257BAB.002B1F3E-C1257BAB.002B2812@de.ibm.com>
2013-07-17 16:00 ` [PATCH v7 0/5] kdump: Allow ELF header creation in new kernel Michael Holzheu
2013-07-17 21:42   ` Vivek Goyal [this message]
2013-07-18 10:40     ` Michael Holzheu
2013-07-18 10:47       ` Martin Schwidefsky
2013-07-18 13:35         ` Vivek Goyal
2013-07-19  6:50           ` Martin Schwidefsky
2013-07-19 13:35             ` Vivek Goyal
2013-07-19 14:20               ` Martin Schwidefsky
2013-07-18 13:27       ` Vivek Goyal
2013-07-18 14:31         ` Michael Holzheu
2013-07-18 14:38           ` Vivek Goyal
2013-07-16 16:18 Michael Holzheu
2013-07-16 17:24 ` Vivek Goyal
2013-07-17 21:32   ` Andrew Morton

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=20130717214207.GB27633@redhat.com \
    --to=vgoyal@redhat.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=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