[PATCH] kexec jump: fix code size checking

Previous thread: Re: pthread_create() slow for many threads; also time to revisit 64b context switch optimization? by Pardo on Tuesday, August 12, 2008 - 5:45 pm. (27 messages)

Next thread: Re: HPET regression in 2.6.26 versus 2.6.25 -- experimental revert for 2.6.27 failed by David Witbrodt on Tuesday, August 12, 2008 - 6:17 pm. (2 messages)
From: Huang Ying
Date: Tuesday, August 12, 2008 - 6:04 pm

Fix building issue when CONFIG_KEXEC=n. Thanks to Vivek Goyal for his
reminding.

Signed-off-by: Huang Ying <ying.huang@intel.com>

---
 include/asm-x86/kexec.h |    3 +++
 1 file changed, 3 insertions(+)

--- a/include/asm-x86/kexec.h
+++ b/include/asm-x86/kexec.h
@@ -43,6 +43,9 @@
 
 #ifdef CONFIG_X86_32
 # define KEXEC_CONTROL_CODE_MAX_SIZE	2048
+# ifndef CONFIG_KEXEC
+#  define kexec_control_code_size	0
+# endif
 #endif
 
 #ifndef __ASSEMBLY__


--

From: Simon Horman
Date: Tuesday, August 12, 2008 - 7:47 pm

Is it impossible to skip the linker check in the !CONFIG_KEXEC case?

--

From: Huang Ying
Date: Tuesday, August 12, 2008 - 8:05 pm

It is possible. I think there are several ways to do that.

1) use #ifdef in vmlinux_32.lds.S, such as:

#ifdef CONFIG_KEXEC
ASSERT(kexec_control_code_size <= KEXEC_CONTROL_CODE_MAX_SIZE,
       "kexec control code size is too big")
#endif

2) #define a macro for kexec check ld script in asm/kexec.h, such as:

#define LD_CHECK_KEXEC()	ASSERT(kexec_control_code_size <= KEXEC_CONTROL_CODE_MAX_SIZE, \
				       "kexec control code size is too big")

and use that in vmlinux_32.lds.S.

3) #define kexec_control_code_size 0. So that the check can be passed
always. And, code size = 0 is reasonable for no code (CONFIG_KEXEC=n).


I think 3) is better. What do you think about?

Best Regards,
Huang Ying


--

From: Eric W. Biederman
Date: Tuesday, August 12, 2008 - 8:40 pm

4) Put the code is a special section .text.kexec? and have the linker
   always do the size comparison and the computation of the section size.

The fewer conditionals we have the less likely something is to break.

Eric
--

From: Huang Ying
Date: Tuesday, August 12, 2008 - 10:18 pm

On Tue, 2008-08-12 at 20:40 -0700, Eric W. Biederman wrote:

Yes. This one is good. But I think current one is acceptable too.

Best Regards,
Huang Ying


--

From: Simon Horman
Date: Tuesday, August 12, 2008 - 10:51 pm

If you really think that 1) is the best way

Acked-by: Simon Horman <horms@verge.net.au>

--

From: Simon Horman
Date: Tuesday, August 12, 2008 - 8:48 pm

Hi Huang,

I think that 1) with possibly the slight variation of moving
#include <asm/kexec.h> inside #ifdef CONFIG_KEXEC is better
because it avoids introducing kexec_control_code_size,
which is currently only used in arch/x86/kernel/relocate_kernel_32.S
and arch/x86/kernel/vmlinux_32.lds.S, into kexec.h.

/* Link time checks */

#ifdef CONFIG_KEXEC
#include <asm/kexec.h>

ASSERT(kexec_control_code_size <= KEXEC_CONTROL_CODE_MAX_SIZE,
       "kexec control code size is too big")
#endif


My second preference would be 3) as it seems simpler than 2).

--

From: Vivek Goyal
Date: Wednesday, August 13, 2008 - 6:21 am

I think 1) is good enough.

Thanks
Vivek
--

From: Vivek Goyal
Date: Wednesday, August 13, 2008 - 6:19 am

I think Andrew already fixed it. Right way is to put code in vmlinux.lds.S
under #ifdef CONFIG_KEXEC, than defining the symbol kexec_control_code_size
if CONFIG_KEXEC=n

Thanks
Vivek
--

From: Andrew Morton
Date: Wednesday, August 13, 2008 - 10:07 am

I was wondering about that.

I resurrected that patch.
--

Previous thread: Re: pthread_create() slow for many threads; also time to revisit 64b context switch optimization? by Pardo on Tuesday, August 12, 2008 - 5:45 pm. (27 messages)

Next thread: Re: HPET regression in 2.6.26 versus 2.6.25 -- experimental revert for 2.6.27 failed by David Witbrodt on Tuesday, August 12, 2008 - 6:17 pm. (2 messages)