All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xunlei Pang <xpang@redhat.com>
To: Dave Young <dyoung@redhat.com>, Xunlei Pang <xlpang@redhat.com>
Cc: Baoquan He <bhe@redhat.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 2/2] kexec: Consider crashk_low_res in sanity_check_segment_list()
Date: Wed, 17 Aug 2016 15:43:33 +0800	[thread overview]
Message-ID: <57B415A5.60104@redhat.com> (raw)
In-Reply-To: <20160817072420.GD5498@dhcp-128-65.nay.redhat.com>

On 2016/08/17 at 15:24, Dave Young wrote:
> Hi, Xunlei,
>
> On 08/17/16 at 09:50am, Xunlei Pang wrote:
>> We have crashk_res only in most cases, but sometimes we have
>> crashk_low_res.
>>
>> For example, on 64-bit x86 systems, when "crashkernel=32M,high"
>> combined with "crashkernel=128M,low" is used, so some segments
>> may have the chance to be loaded into crashk_low_res area. We
>> can't fail it as a memory violation in these cases.
>>
>> Thus, we add the case to regard the segment as valid if it is
>> within crashk_low_res.
> crashkernel low is meant for swiotlb, it can be reserved automaticlly
> in case there's only crashkernel high specified in cmdline, I'm not
> sure it is useful to use crashk_res_low for other purpose and
> likely kdump can fail in the case. 
>
> I'm not sure it is really necessary to add this check now, we may
> handle it only when there is an actual use case and bug report in
> the future.

Thanks for the review.
The reason I added this is that crashk_res is allowed to be shrunk, so the segment
will surely fall into crashk_low_res if crashk_res was shrunk to be a small range.

But yes, this should be a corner case, but seems it does no harm adding this check.
Anyway, if you think it's not necessary, let's simply ignore it :-)

Regards,
Xunlei

>
> Thanks
> Dave
>> Signed-off-by: Xunlei Pang <xlpang@redhat.com>
>> ---
>>  kernel/kexec_core.c | 11 ++++++++---
>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> index 707d18e..9012a60 100644
>> --- a/kernel/kexec_core.c
>> +++ b/kernel/kexec_core.c
>> @@ -248,9 +248,14 @@ int sanity_check_segment_list(struct kimage *image)
>>  			mstart = image->segment[i].mem;
>>  			mend = mstart + image->segment[i].memsz - 1;
>>  			/* Ensure we are within the crash kernel limits */
>> -			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
>> -			    (mend > phys_to_boot_phys(crashk_res.end)))
>> -				return -EADDRNOTAVAIL;
>> +			if ((mstart >= phys_to_boot_phys(crashk_res.start)) &&
>> +			    (mend <= phys_to_boot_phys(crashk_res.end)))
>> +				continue;
>> +			if ((mstart >= phys_to_boot_phys(crashk_low_res.start)) &&
>> +			    (mend <= phys_to_boot_phys(crashk_low_res.end)))
>> +				continue;
>> +
>> +			return -EADDRNOTAVAIL;
>>  		}
>>  	}
>>  
>> -- 
>> 1.8.3.1
>>
> _______________________________________________
> 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 <xpang@redhat.com>
To: Dave Young <dyoung@redhat.com>, Xunlei Pang <xlpang@redhat.com>
Cc: Baoquan He <bhe@redhat.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 2/2] kexec: Consider crashk_low_res in sanity_check_segment_list()
Date: Wed, 17 Aug 2016 15:43:33 +0800	[thread overview]
Message-ID: <57B415A5.60104@redhat.com> (raw)
In-Reply-To: <20160817072420.GD5498@dhcp-128-65.nay.redhat.com>

On 2016/08/17 at 15:24, Dave Young wrote:
> Hi, Xunlei,
>
> On 08/17/16 at 09:50am, Xunlei Pang wrote:
>> We have crashk_res only in most cases, but sometimes we have
>> crashk_low_res.
>>
>> For example, on 64-bit x86 systems, when "crashkernel=32M,high"
>> combined with "crashkernel=128M,low" is used, so some segments
>> may have the chance to be loaded into crashk_low_res area. We
>> can't fail it as a memory violation in these cases.
>>
>> Thus, we add the case to regard the segment as valid if it is
>> within crashk_low_res.
> crashkernel low is meant for swiotlb, it can be reserved automaticlly
> in case there's only crashkernel high specified in cmdline, I'm not
> sure it is useful to use crashk_res_low for other purpose and
> likely kdump can fail in the case. 
>
> I'm not sure it is really necessary to add this check now, we may
> handle it only when there is an actual use case and bug report in
> the future.

Thanks for the review.
The reason I added this is that crashk_res is allowed to be shrunk, so the segment
will surely fall into crashk_low_res if crashk_res was shrunk to be a small range.

But yes, this should be a corner case, but seems it does no harm adding this check.
Anyway, if you think it's not necessary, let's simply ignore it :-)

Regards,
Xunlei

>
> Thanks
> Dave
>> Signed-off-by: Xunlei Pang <xlpang@redhat.com>
>> ---
>>  kernel/kexec_core.c | 11 ++++++++---
>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> index 707d18e..9012a60 100644
>> --- a/kernel/kexec_core.c
>> +++ b/kernel/kexec_core.c
>> @@ -248,9 +248,14 @@ int sanity_check_segment_list(struct kimage *image)
>>  			mstart = image->segment[i].mem;
>>  			mend = mstart + image->segment[i].memsz - 1;
>>  			/* Ensure we are within the crash kernel limits */
>> -			if ((mstart < phys_to_boot_phys(crashk_res.start)) ||
>> -			    (mend > phys_to_boot_phys(crashk_res.end)))
>> -				return -EADDRNOTAVAIL;
>> +			if ((mstart >= phys_to_boot_phys(crashk_res.start)) &&
>> +			    (mend <= phys_to_boot_phys(crashk_res.end)))
>> +				continue;
>> +			if ((mstart >= phys_to_boot_phys(crashk_low_res.start)) &&
>> +			    (mend <= phys_to_boot_phys(crashk_low_res.end)))
>> +				continue;
>> +
>> +			return -EADDRNOTAVAIL;
>>  		}
>>  	}
>>  
>> -- 
>> 1.8.3.1
>>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2016-08-17  7:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-17  1:50 [PATCH v2 1/2] kexec: Introduce "/sys/kernel/kexec_crash_low_size" Xunlei Pang
2016-08-17  1:50 ` Xunlei Pang
2016-08-17  1:50 ` [PATCH v2 2/2] kexec: Consider crashk_low_res in sanity_check_segment_list() Xunlei Pang
2016-08-17  1:50   ` Xunlei Pang
2016-08-17  7:24   ` Dave Young
2016-08-17  7:24     ` Dave Young
2016-08-17  7:43     ` Xunlei Pang [this message]
2016-08-17  7:43       ` Xunlei Pang
2016-08-17  8:20 ` [PATCH v2 1/2] kexec: Introduce "/sys/kernel/kexec_crash_low_size" Dave Young
2016-08-17  8:20   ` Dave Young
2016-08-24  1:11   ` Yinghai Lu
2016-08-24  1:11     ` Yinghai Lu
2016-08-24  8:20     ` Dave Young
2016-08-24  8:20       ` Dave Young
2016-08-24 11:37       ` Xunlei Pang
2016-08-24 11:37         ` 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=57B415A5.60104@redhat.com \
    --to=xpang@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.