From: Xunlei Pang <xpang@redhat.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Baoquan He <bhe@redhat.com>, Minfei Huang <mhuang@redhat.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
ebiederm@xmission.com, akpm@linux-foundation.org,
Vivek Goyal <vgoyal@redhat.com>
Subject: Re: [PATCH v2] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()
Date: Tue, 5 Apr 2016 18:23:31 +0800 [thread overview]
Message-ID: <57039223.7020903@redhat.com> (raw)
In-Reply-To: <20160405111316.2fa4772c@holzheu>
On 2016/04/05 at 17:13, Michael Holzheu wrote:
> Hello Xunlei,
>
> On Tue, 5 Apr 2016 15:09:59 +0800
> Xunlei Pang <xlpang@redhat.com> wrote:
>> Commit 3f625002581b ("kexec: introduce a protection mechanism
>> for the crashkernel reserved memory") is a similar mechanism
>> for protecting the crash kernel reserved memory to previous
>> crash_map/unmap_reserved_pages() implementation, the new one
>> is more generic in name and cleaner in code (besides, some
>> arch may not be allowed to unmap the pgtable).
>>
>> Therefore, this patch consolidates them, and uses the new
>> arch_kexec_protect(unprotect)_crashkres() to replace former
>> crash_map/unmap_reserved_pages() which by now has been only
>> used by S390.
>>
>> The consolidation work needs the crash memory to be mapped
>> initially, so get rid of S390 crash kernel memblock removal
>> in reserve_crashkernel().
Oops, the final paragraph of the changelog should be changed to:
The consolidation work needs the crash memory to be mapped
initially, this is done in machine_kdump_pm_init() which is run
after reserve_crashkernel(). Once kdump kernel is loaded, the
new arch_kexec_protect_crashkres() implemented for S390 will
actually unmap the pgtable like before.
> If you fix this comment, I am fine with your patch.
>
> Acked-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
>
Thanks,
Xunlei
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Xunlei Pang <xpang@redhat.com>
To: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
akpm@linux-foundation.org, ebiederm@xmission.com,
Minfei Huang <mhuang@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
Baoquan He <bhe@redhat.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>
Subject: Re: [PATCH v2] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres()
Date: Tue, 5 Apr 2016 18:23:31 +0800 [thread overview]
Message-ID: <57039223.7020903@redhat.com> (raw)
In-Reply-To: <20160405111316.2fa4772c@holzheu>
On 2016/04/05 at 17:13, Michael Holzheu wrote:
> Hello Xunlei,
>
> On Tue, 5 Apr 2016 15:09:59 +0800
> Xunlei Pang <xlpang@redhat.com> wrote:
>> Commit 3f625002581b ("kexec: introduce a protection mechanism
>> for the crashkernel reserved memory") is a similar mechanism
>> for protecting the crash kernel reserved memory to previous
>> crash_map/unmap_reserved_pages() implementation, the new one
>> is more generic in name and cleaner in code (besides, some
>> arch may not be allowed to unmap the pgtable).
>>
>> Therefore, this patch consolidates them, and uses the new
>> arch_kexec_protect(unprotect)_crashkres() to replace former
>> crash_map/unmap_reserved_pages() which by now has been only
>> used by S390.
>>
>> The consolidation work needs the crash memory to be mapped
>> initially, so get rid of S390 crash kernel memblock removal
>> in reserve_crashkernel().
Oops, the final paragraph of the changelog should be changed to:
The consolidation work needs the crash memory to be mapped
initially, this is done in machine_kdump_pm_init() which is run
after reserve_crashkernel(). Once kdump kernel is loaded, the
new arch_kexec_protect_crashkres() implemented for S390 will
actually unmap the pgtable like before.
> If you fix this comment, I am fine with your patch.
>
> Acked-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
>
Thanks,
Xunlei
next prev parent reply other threads:[~2016-04-05 10:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 7:09 [PATCH v2] s390/kexec: Consolidate crash_map/unmap_reserved_pages() and arch_kexec_protect(unprotect)_crashkres() Xunlei Pang
2016-04-05 7:09 ` Xunlei Pang
2016-04-05 9:13 ` Michael Holzheu
2016-04-05 9:13 ` Michael Holzheu
2016-04-05 10:23 ` Xunlei Pang [this message]
2016-04-05 10:23 ` Xunlei Pang
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=57039223.7020903@redhat.com \
--to=xpang@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.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=mhuang@redhat.com \
--cc=vgoyal@redhat.com \
--cc=xlpang@redhat.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.