From: ebiederm@xmission.com (Eric W. Biederman)
To: Amerigo Wang <amwang@redhat.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: Tue, 11 Aug 2009 19:43:30 -0700 [thread overview]
Message-ID: <m1ws5992gd.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4A822404.9030603@redhat.com> (Amerigo Wang's message of "Wed\, 12 Aug 2009 10\:08\:04 +0800")
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.
Eric
next prev parent reply other threads:[~2009-08-12 2:43 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 [this message]
2009-08-12 3:14 ` Amerigo Wang
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=m1ws5992gd.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=amwang@redhat.com \
--cc=andi@firstfloor.org \
--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