From: Xunlei Pang <xlpang@redhat.com>
To: Dave Young <dyoung@redhat.com>
Cc: akpm@linux-foundation.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, vgoyal@redhat.com,
Eric Biederman <ebiederm@xmission.com>
Subject: Re: [PATCH 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()
Date: Thu, 24 Dec 2015 14:05:56 +0800 [thread overview]
Message-ID: <567B8B44.9070807@redhat.com> (raw)
In-Reply-To: <20151224055425.GC3480@dhcp-128-65.nay.redhat.com>
On 12/24/2015 at 01:54 PM, Dave Young wrote:
> Ccing Vivek
>
> On 12/23/15 at 07:12pm, Xunlei Pang wrote:
>> Implement the protection method for the crash kernel memory
>> reservation for the 64-bit x86 kdump.
>>
>> Signed-off-by: Xunlei Pang <xlpang@redhat.com>
>> ---
>> Only provided x86_64 implementation, as I've only tested on x86_64 so far.
>>
>> arch/x86/kernel/machine_kexec_64.c | 43 ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 43 insertions(+)
>>
>> diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
>> index 819ab3f..a3d289c 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b/arch/x86/kernel/machine_kexec_64.c
>> @@ -536,3 +536,46 @@ overflow:
>> return -ENOEXEC;
>> }
>> #endif /* CONFIG_KEXEC_FILE */
>> +
>> +#ifdef CONFIG_KEXEC_CORE
> The file is only compiled when CONFIG_KEXEC_CORE=y so #ifdef is not necessary
Yes, indeed. I'll remove this macro and send v2 later.
>
>> +static int
>> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
>> +{
>> + struct page *page;
>> + unsigned int nr_pages;
>> +
>> + if (!start || !end || start >= end)
>> + return 0;
>> +
>> + page = pfn_to_page(start >> PAGE_SHIFT);
>> + nr_pages = (end + 1 - start) >> PAGE_SHIFT;
>> + if (protect)
>> + return set_pages_ro(page, nr_pages);
>> + else
>> + return set_pages_rw(page, nr_pages);
> May use set_memory_ro/rw to avoid converting to *page?
on x86 it just a wrapper of set_memory_ro/rw, I think both are ok.
>
>> +}
>> +
>> +static void kexec_mark_crashkres(bool protect)
>> +{
>> + unsigned long control;
>> +
>> + kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
>> +
>> + /* Don't touch the control code page used in crash_kexec().*/
>> + control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
>> + /* Control code page is located in the 2nd page. */
>> + control = control + PAGE_SIZE;
>> + kexec_mark_range(crashk_res.start, control - 1, protect);
>> + kexec_mark_range(control + PAGE_SIZE, crashk_res.end, protect);
> X86 kexec will copy the page while kexecing, could you check if we can move
> that copying to earliyer while kexec loading, maybe machine_kexec_prepare so
> that we can make a arch-independent implementation.
For some arch, may use huge tlb directly to do the kernel mapping,
in such cases, we can't implement this function. So I think it should
be arch-dependent.
Regards,
Xunlei
>
>> +}
>> +
>> +void arch_kexec_protect_crashkres(void)
>> +{
>> + kexec_mark_crashkres(true);
>> +}
>> +
>> +void arch_kexec_unprotect_crashkres(void)
>> +{
>> + kexec_mark_crashkres(false);
>> +}
>> +#endif
>> --
>> 2.5.0
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
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 <xlpang@redhat.com>
To: Dave Young <dyoung@redhat.com>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
akpm@linux-foundation.org, Eric Biederman <ebiederm@xmission.com>,
vgoyal@redhat.com
Subject: Re: [PATCH 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()
Date: Thu, 24 Dec 2015 14:05:56 +0800 [thread overview]
Message-ID: <567B8B44.9070807@redhat.com> (raw)
In-Reply-To: <20151224055425.GC3480@dhcp-128-65.nay.redhat.com>
On 12/24/2015 at 01:54 PM, Dave Young wrote:
> Ccing Vivek
>
> On 12/23/15 at 07:12pm, Xunlei Pang wrote:
>> Implement the protection method for the crash kernel memory
>> reservation for the 64-bit x86 kdump.
>>
>> Signed-off-by: Xunlei Pang <xlpang@redhat.com>
>> ---
>> Only provided x86_64 implementation, as I've only tested on x86_64 so far.
>>
>> arch/x86/kernel/machine_kexec_64.c | 43 ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 43 insertions(+)
>>
>> diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
>> index 819ab3f..a3d289c 100644
>> --- a/arch/x86/kernel/machine_kexec_64.c
>> +++ b/arch/x86/kernel/machine_kexec_64.c
>> @@ -536,3 +536,46 @@ overflow:
>> return -ENOEXEC;
>> }
>> #endif /* CONFIG_KEXEC_FILE */
>> +
>> +#ifdef CONFIG_KEXEC_CORE
> The file is only compiled when CONFIG_KEXEC_CORE=y so #ifdef is not necessary
Yes, indeed. I'll remove this macro and send v2 later.
>
>> +static int
>> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
>> +{
>> + struct page *page;
>> + unsigned int nr_pages;
>> +
>> + if (!start || !end || start >= end)
>> + return 0;
>> +
>> + page = pfn_to_page(start >> PAGE_SHIFT);
>> + nr_pages = (end + 1 - start) >> PAGE_SHIFT;
>> + if (protect)
>> + return set_pages_ro(page, nr_pages);
>> + else
>> + return set_pages_rw(page, nr_pages);
> May use set_memory_ro/rw to avoid converting to *page?
on x86 it just a wrapper of set_memory_ro/rw, I think both are ok.
>
>> +}
>> +
>> +static void kexec_mark_crashkres(bool protect)
>> +{
>> + unsigned long control;
>> +
>> + kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
>> +
>> + /* Don't touch the control code page used in crash_kexec().*/
>> + control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page));
>> + /* Control code page is located in the 2nd page. */
>> + control = control + PAGE_SIZE;
>> + kexec_mark_range(crashk_res.start, control - 1, protect);
>> + kexec_mark_range(control + PAGE_SIZE, crashk_res.end, protect);
> X86 kexec will copy the page while kexecing, could you check if we can move
> that copying to earliyer while kexec loading, maybe machine_kexec_prepare so
> that we can make a arch-independent implementation.
For some arch, may use huge tlb directly to do the kernel mapping,
in such cases, we can't implement this function. So I think it should
be arch-dependent.
Regards,
Xunlei
>
>> +}
>> +
>> +void arch_kexec_protect_crashkres(void)
>> +{
>> + kexec_mark_crashkres(true);
>> +}
>> +
>> +void arch_kexec_unprotect_crashkres(void)
>> +{
>> + kexec_mark_crashkres(false);
>> +}
>> +#endif
>> --
>> 2.5.0
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2015-12-24 6:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-23 11:12 [PATCH 1/2] kexec: Introduce a protection mechanism for the crashkernel reserved memory Xunlei Pang
2015-12-23 11:12 ` Xunlei Pang
2015-12-23 11:12 ` [PATCH 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres() Xunlei Pang
2015-12-23 11:12 ` Xunlei Pang
2015-12-24 5:54 ` Dave Young
2015-12-24 5:54 ` Dave Young
2015-12-24 6:05 ` Xunlei Pang [this message]
2015-12-24 6:05 ` Xunlei Pang
2015-12-24 6:16 ` Dave Young
2015-12-24 6:16 ` Dave Young
2015-12-24 6:44 ` Xunlei Pang
2015-12-24 6:44 ` Xunlei Pang
2015-12-28 6:32 ` Xunlei Pang
2015-12-28 6:32 ` Xunlei Pang
2015-12-28 12:14 ` Minfei Huang
2015-12-28 12:14 ` Minfei Huang
2015-12-28 12:20 ` Minfei Huang
2015-12-28 12:20 ` Minfei Huang
2015-12-29 11:02 ` Xunlei Pang
2015-12-29 11:02 ` Xunlei Pang
2015-12-26 15:21 ` Minfei Huang
2015-12-26 15:21 ` Minfei Huang
2015-12-28 1:57 ` Xunlei Pang
2016-03-22 18:39 ` [PATCH 1/2] kexec: Introduce a protection mechanism for the crashkernel reserved memory Andrew Morton
2016-03-22 18:39 ` 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=567B8B44.9070807@redhat.com \
--to=xlpang@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@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.