Re: [PATCH v2 2/2] kexec: Provide arch_kexec_protect(unprotect)_crashkres()

[Xunlei Pang]

On 01/07/2016 at 10:14 AM, Xunlei Pang wrote:
> On 01/07/2016 at 01:08 AM, Minfei Huang wrote:
>> On 01/06/16 at 05:50pm, Xunlei Pang wrote:
>>> diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c
>>> index 819ab3f..cda867d 100644
>>> --- a/arch/x86/kernel/machine_kexec_64.c
>>> +++ b/arch/x86/kernel/machine_kexec_64.c
>>> @@ -536,3 +536,44 @@ overflow:
>>>  	return -ENOEXEC;
>>>  }
>>>  #endif /* CONFIG_KEXEC_FILE */
>>> +
>>> +static int
>>> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
>>> +{
>>> +	struct page *page;
>>> +	unsigned int nr_pages;
>>> +
>>> +	/* For physical range: [start, end] */
>>> +	if (!start || !end || start > end)
>>> +		return 0;
>> Hi, Xunlei.
>>
>>         if (start > end)
>>                 return 0;
> If both start and end are zero, we want to return directly, so the two
> more check doesn't hurt.
>
>> See the below comment.
>>> +
>>> +	page = pfn_to_page(start >> PAGE_SHIFT);
>>> +	nr_pages = (end + PAGE_SIZE - start) >> PAGE_SHIFT;
>> As I commented in last version, it is better to cover the case if the
>> range from start to end acrosses two pages.
> right.
>
>>> +	if (protect)
>>> +		return set_pages_ro(page, nr_pages);
>>> +	else
>>> +		return set_pages_rw(page, nr_pages);
>>> +}
>>> +
>>> +static void kexec_mark_crashkres(bool protect)
>>> +{
>>> +	unsigned long control;
>>> +
>>> +	kexec_mark_range(crashk_low_res.start, crashk_low_res.end, protect);
>> Adding the following if test to test crashk_low_res is better. Then we
>> do not need to test if start or end is equal to 0 in kexec_mark_range.
>>
>>         if (crashk_low_res.start != crashk_low_res.end) {
>>                 kexec_mark_range(crashk_low_res.start,
>>                                 crashk_low_res.end, protect);
>>         }
> The checks in kexec_mark_range() will handle the case, it's not
> performance-critical path and will make the code less clean.
>
>>> +
>>> +	/* 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. */
>>> +	kexec_mark_range(crashk_res.start, control + PAGE_SIZE - 1, protect);
>>> +	kexec_mark_range(control + 2 * PAGE_SIZE, crashk_res.end, protect);
>> I think it is more readable, if we use MACRO KEXEC_CONTROL_PAGE_SIZE,
>> instead of using 2*PAGE_SIZE directly.
> OK.
>
> How about the following update:
>
> +static int
> +kexec_mark_range(unsigned long start, unsigned long end, bool protect)
> +{
> +       struct page *page;
> +       unsigned int nr_pages;
> +
> +       /* For physical range: [start, end] */
> +       if (!start || !end || start > end)
> +               return 0;
> +
> +       page = pfn_to_page(start >> PAGE_SHIFT);
> +       nr_pages = (end >> PAGE_SHIFT) - (start >> PAGE_SHIFT) + 1;
> +       if (protect)
> +               return set_pages_ro(page, nr_pages);
> +       else
> +               return set_pages_rw(page, nr_pages);
> +}
> +
> +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. */
> +       kexec_mark_range(crashk_res.start, control + PAGE_SIZE - 1, protect);
> +       control += KEXEC_CONTROL_PAGE_SIZE;

In fact, control code page is only 1 page, using control + 2*PAGE_SIZE is clearer.
For example, if we have more other type pages following it. Anyway this is not
that important.

Regards,
Xunlei

> +       kexec_mark_range(control, crashk_res.end, protect);
> +}
> +
> +void arch_kexec_protect_crashkres(void)
> +{
> +       kexec_mark_crashkres(true);
> +}
> +
> +void arch_kexec_unprotect_crashkres(void)
> +{
> +       kexec_mark_crashkres(false);
> +}
>
>> Thanks
>> Minfei
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@xxxxxxxxxxxxxxxxxxx
>> http://lists.infradead.org/mailman/listinfo/kexec
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/