Two "echo 0 > /sys/kernel/kexec_crash_size" OOPSes kernel. Also
content of this file is invalid after first shrink to zero: it shows 1
instead of 0.

This patch fixes it.

Signed-off-by: Vitaly Mayatskikh <v.mayatskih@gmail.com>

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 87ebe8a..474a847 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1134,11 +1134,9 @@ int crash_shrink_memory(unsigned long new_size)
 
 	free_reserved_phys_range(end, crashk_res.end);
 
-	if (start == end) {
-		crashk_res.end = end;
+	if (start == end)
 		release_resource(&crashk_res);
-	} else
-		crashk_res.end = end - 1;
+	crashk_res.end = end - 1;
 
 unlock:
 	mutex_unlock(&kexec_mutex);

-- 
wbr, Vitaly
--

[ message continues ]

Hmmm, I certainly did tests for 'echo 0 > kexec_crash_size' when I
worked on this, but I didn't get any oops. Can you show me the full
oops?


If we do this, crashk_res.end will be ahead of crashk.start.

Thanks.
--

[ message continues ]

Do it twice. start == end condition will work over and over, and
kernel will try to release_resource() again (and that's causes OOPS).

This scenario is unlikely to happen often (root privs, valid
crashkernel= in cmdline, dump-capture kernel not loaded), I hit it
only by chance.

-- 
wbr, Vitaly
--

[ message continues ]

Hmm, I see. ACK to your patch.

Thanks much!

--

[ message continues ]