Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a8a11f06973fa63ad692a8f97694cb5eeb70b3f3
Commit:     a8a11f06973fa63ad692a8f97694cb5eeb70b3f3
Parent:     dfbab7540569679a91cf43208eff4ef3f4500a5f
Author:     Rusty Russell <[EMAIL PROTECTED]>
AuthorDate: Fri Jul 27 13:35:43 2007 +1000
Committer:  Linus Torvalds <[EMAIL PROTECTED]>
CommitDate: Sat Jul 28 19:53:36 2007 -0700

    Fix lguest bzImage loading with CONFIG_RELOCATABLE=y
    
    Jason Yeh sent his crashing .config: bzImages made with
    CONFIG_RELOCATABLE=y put the relocs where the BSS is expected, and we
    crash with unusual results such as:
    
        lguest: unhandled trap 14 at 0xc0122ae1 (0xa9)
    
    Relying on BSS being zero was merely laziness on my part, and
    unfortunately, lguest doesn't go through the normal startup path (which
    does this in asm).
    
    Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
    Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
 drivers/lguest/lguest.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/lguest/lguest.c b/drivers/lguest/lguest.c
index 6dfe568..3386b0e 100644
--- a/drivers/lguest/lguest.c
+++ b/drivers/lguest/lguest.c
@@ -1019,6 +1019,11 @@ __init void lguest_init(void *boot)
         * the normal data segment to get through booting. */
        asm volatile ("mov %0, %%fs" : : "r" (__KERNEL_DS) : "memory");
 
+       /* Clear the part of the kernel data which is expected to be zero.
+        * Normally it will be anyway, but if we're loading from a bzImage with
+        * CONFIG_RELOCATALE=y, the relocations will be sitting here. */
+       memset(__bss_start, 0, __bss_stop - __bss_start);
+
        /* The Host uses the top of the Guest's virtual address space for the
         * Host<->Guest Switcher, and it tells us how much it needs in
         * lguest_data.reserve_mem, set up on the LGUEST_INIT hypercall. */
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to