From: Amerigo Wang <amwang@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
Neil Horman <nhorman@redhat.com>,
Andi Kleen <andi@firstfloor.org>,
akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [RFC Patch 2/2] kexec: allow to shrink reserved memory
Date: Wed, 12 Aug 2009 11:14:45 +0800 [thread overview]
Message-ID: <4A8233A5.2020501@redhat.com> (raw)
In-Reply-To: <m1ws5992gd.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Amerigo Wang <amwang@redhat.com> writes:
>
>
>> Eric W. Biederman wrote:
>>
>>> Amerigo Wang <amwang@redhat.com> writes:
>>>
>>>
>>>
>>>> Eric W. Biederman wrote:
>>>>
>>>>
>>>>> Amerigo Wang <amwang@redhat.com> writes:
>>>>>
>>>>>
>>>>>
>>>>>> This patch implements shrinking the reserved memory for crash kernel,
>>>>>> if it is more than enough.
>>>>>>
>>>>>> For example, if you have already reserved 128M, now you just want 100M,
>>>>>> you can do:
>>>>>>
>>>>>> # echo $((100*1024*1024)) > /sys/kernel/kexec_crash_size
>>>>>>
>>>>>>
>>>>> This patch looks like a reasonable start.
>>>>>
>>>>> However once a crash kernel image is loaded we have already told that
>>>>> image about the memory that is available and what you are doing here
>>>>> will go and stop on the memory that is reserved but not yet used,
>>>>> totally breaking the DMA protections. AKA we know the memory is safe
>>>>> from ongoing DMAs because it has lain fallow since boot up.
>>>>>
>>>>> The only safe thing to do is to reduce the memory size before (possibly
>>>>> just before) we load the crash kernel. Which means we should only
>>>>> be allowed to shrink the size when nothing is loaded, exactly the
>>>>> opposite of what you have implemented.
>>>>>
>>>>>
>>>>>
>>>> Confused, why just loading the crash kernel makes it unsafe?
>>>> DMA should be avoided when reserving that memory during boot, shouldn't it?
>>>>
>>>>
>>> Yes. But you are removing the reservation and starting DMA on memory
>>> we have told the crash kernel it can use.
>>>
>>>
>> We can modify the info given to the crash kernel.
>>
>
> Only by unloading and reloading.
>
>
>>>> I know I missed the part that freeing memory before loading, but if it is safe
>>>> before loading, how can it be unsafe after that?
>>>>
>>>>
>>> We tell the crash kernel when loading it, it can use all of the reserved memory.
>>>
>>>
>> Yeah, but we should reload the kernel after shrinking the memory, it is not
>> surprised that doing this is necessary...
>>
>
> So unload the crash kernel first. If you don't you open a race where
> many of the guarantees we make for the crash kernel about the state of
> the memory it might be using are not true.
>
> In general I expect we will be able to do this all before we load the
> crash kernel the first time. But at least we should not need to reboot
> things if there is a problem.
>
Ok, thanks for your explanation.
I will drop patch 1/2, since we will move it to kexec.
I will put patch 2/2 into my "crashkernel=auto" patch set, and resend
them all.
Thanks.
next prev parent reply other threads:[~2009-08-12 3:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-11 10:39 [RFC Patch 1/2] kexec: show memory info in /proc/iomem Amerigo Wang
2009-08-11 10:39 ` [RFC Patch 2/2] kexec: allow to shrink reserved memory Amerigo Wang
2009-08-11 10:46 ` Neil Horman
2009-08-11 20:55 ` Yu, Fenghua
2009-08-12 1:32 ` Amerigo Wang
2009-08-11 19:57 ` Eric W. Biederman
2009-08-12 1:25 ` Amerigo Wang
2009-08-12 1:46 ` Eric W. Biederman
2009-08-12 2:08 ` Amerigo Wang
2009-08-12 2:43 ` Eric W. Biederman
2009-08-12 3:14 ` Amerigo Wang [this message]
2009-08-11 19:49 ` [RFC Patch 1/2] kexec: show memory info in /proc/iomem Eric W. Biederman
2009-08-12 1:17 ` Amerigo Wang
2009-08-12 1:51 ` Eric W. Biederman
2009-08-12 2:15 ` Amerigo Wang
2009-08-12 2:39 ` Eric W. Biederman
2009-08-11 20:50 ` Yu, Fenghua
2009-08-12 1:27 ` Amerigo Wang
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=4A8233A5.2020501@redhat.com \
--to=amwang@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=ebiederm@xmission.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nhorman@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox