diff options
| author | Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> | 2018-08-20 13:47:32 +0530 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2019-02-12 19:46:07 +0100 |
| commit | e7226c67a17dd86c57b5f15bb4daf4358948fb7d (patch) | |
| tree | 15011332ed2ad441a0e2d62d79d1a337cc6bd6e6 /virt | |
| parent | 9698e2687b226b0e8d44e79c657870f6ac10b041 (diff) | |
| download | linux-stable-e7226c67a17dd86c57b5f15bb4daf4358948fb7d.tar.gz linux-stable-e7226c67a17dd86c57b5f15bb4daf4358948fb7d.tar.bz2 linux-stable-e7226c67a17dd86c57b5f15bb4daf4358948fb7d.zip | |
powerpc/fadump: Do not allow hot-remove memory from fadump reserved area.
[ Upstream commit 0db6896ff6332ba694f1e61b93ae3b2640317633 ]
For fadump to work successfully there should not be any holes in reserved
memory ranges where kernel has asked firmware to move the content of old
kernel memory in event of crash. Now that fadump uses CMA for reserved
area, this memory area is now not protected from hot-remove operations
unless it is cma allocated. Hence, fadump service can fail to re-register
after the hot-remove operation, if hot-removed memory belongs to fadump
reserved region. To avoid this make sure that memory from fadump reserved
area is not hot-removable if fadump is registered.
However, if user still wants to remove that memory, he can do so by
manually stopping fadump service before hot-remove operation.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'virt')
0 files changed, 0 insertions, 0 deletions