[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 - 8: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 - 9:17 pm. (2 messages)
To: Eric W. Biederman <ebiederm@...>, Pavel Machek <pavel@...>, <nigel@...>, Rafael J. Wysocki <rjw@...>, Andrew Morton <akpm@...>, Vivek Goyal <vgoyal@...>, <mingo@...>, Linus Torvalds <torvalds@...>
Cc: <linux-kernel@...>, Kexec Mailing List <kexec@...>
Date: Tuesday, August 12, 2008 - 9: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__

--

To: Huang Ying <ying.huang@...>
Cc: Eric W. Biederman <ebiederm@...>, Pavel Machek <pavel@...>, <nigel@...>, Rafael J. Wysocki <rjw@...>, Andrew Morton <akpm@...>, <mingo@...>, Linus Torvalds <torvalds@...>, <linux-kernel@...>, Kexec Mailing List <kexec@...>
Date: Wednesday, August 13, 2008 - 9: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
--

To: Vivek Goyal <vgoyal@...>
Cc: Huang Ying <ying.huang@...>, Eric W. Biederman <ebiederm@...>, Pavel Machek <pavel@...>, <nigel@...>, Rafael J. Wysocki <rjw@...>, <mingo@...>, Linus Torvalds <torvalds@...>, <linux-kernel@...>, Kexec Mailing List <kexec@...>
Date: Wednesday, August 13, 2008 - 1:07 pm

I was wondering about that.

I resurrected that patch.
--

To: Huang Ying <ying.huang@...>
Cc: Eric W. Biederman <ebiederm@...>, Pavel Machek <pavel@...>, <nigel@...>, Rafael J. Wysocki <rjw@...>, Andrew Morton <akpm@...>, Vivek Goyal <vgoyal@...>, <mingo@...>, Linus Torvalds <torvalds@...>, Kexec Mailing List <kexec@...>, <linux-kernel@...>
Date: Tuesday, August 12, 2008 - 10:47 pm

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

--

To: Simon Horman <horms@...>
Cc: Eric W. Biederman <ebiederm@...>, Pavel Machek <pavel@...>, <nigel@...>, Rafael J. Wysocki <rjw@...>, Andrew Morton <akpm@...>, Vivek Goyal <vgoyal@...>, <mingo@...>, Linus Torvalds <torvalds@...>, Kexec Mailing List <kexec@...>, <linux-kernel@...>
Date: Tuesday, August 12, 2008 - 11: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

--

To: Huang Ying <ying.huang@...>
Cc: Simon Horman <horms@...>, Eric W. Biederman <ebiederm@...>, Pavel Machek <pavel@...>, <nigel@...>, Rafael J. Wysocki <rjw@...>, Andrew Morton <akpm@...>, <mingo@...>, Linus Torvalds <torvalds@...>, Kexec Mailing List <kexec@...>, <linux-kernel@...>
Date: Wednesday, August 13, 2008 - 9:21 am

I think 1) is good enough.

Thanks
Vivek
--

To: Huang Ying <ying.huang@...>
Cc: <nigel@...>, Kexec Mailing List <kexec@...>, <linux-kernel@...>, Rafael J. Wysocki <rjw@...>, Eric W. Biederman <ebiederm@...>, Pavel Machek <pavel@...>, Andrew Morton <akpm@...>, Linus Torvalds <torvalds@...>, <mingo@...>, Vivek Goyal <vgoyal@...>
Date: Tuesday, August 12, 2008 - 11: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).

--

To: Huang Ying <ying.huang@...>
Cc: Simon Horman <horms@...>, Pavel Machek <pavel@...>, <nigel@...>, Rafael J. Wysocki <rjw@...>, Andrew Morton <akpm@...>, Vivek Goyal <vgoyal@...>, <mingo@...>, Linus Torvalds <torvalds@...>, Kexec Mailing List <kexec@...>, <linux-kernel@...>
Date: Tuesday, August 12, 2008 - 11: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
--

To: Eric W. Biederman <ebiederm@...>
Cc: Simon Horman <horms@...>, Pavel Machek <pavel@...>, <nigel@...>, Rafael J. Wysocki <rjw@...>, Andrew Morton <akpm@...>, Vivek Goyal <vgoyal@...>, <mingo@...>, Linus Torvalds <torvalds@...>, Kexec Mailing List <kexec@...>, <linux-kernel@...>
Date: Wednesday, August 13, 2008 - 1:18 am

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

--

To: Huang Ying <ying.huang@...>
Cc: Eric W. Biederman <ebiederm@...>, Pavel Machek <pavel@...>, <nigel@...>, Rafael J. Wysocki <rjw@...>, Andrew Morton <akpm@...>, Vivek Goyal <vgoyal@...>, <mingo@...>, Linus Torvalds <torvalds@...>, Kexec Mailing List <kexec@...>, <linux-kernel@...>
Date: Wednesday, August 13, 2008 - 1:51 am

If you really think that 1) is the best way

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

--

Previous thread: Re: pthread_create() slow for many threads; also time to revisit 64b context switch optimization? by Pardo on Tuesday, August 12, 2008 - 8: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 - 9:17 pm. (2 messages)