linux-um archives
 help / color / mirror / Atom feed
From: Blaisorblade <blaisorblade@yahoo.it>
To: Jonathan  <jtester@users.sourceforge.net>
Cc: Jeff Dike <jdike@addtoit.com>,
	user-mode-linux-devel@lists.sourceforge.net
Subject: Re: [uml-devel] possible um l bug
Date: Sun, 25 Jun 2006 17:55:45 +0200	[thread overview]
Message-ID: <200606251755.45664.blaisorblade@yahoo.it> (raw)
In-Reply-To: <E1FsiSR-0003HP-OO@sc8-sf-web5.sourceforge.net>

On Tuesday 20 June 2006 17:48, Jonathan wrote:
> Message body follows:

> I am using user-mode linux on 2.6.16.18

> I my .config everything is resident except some NFS
>> CONFIG_NFS_FS=m

> CONFIG_NFS_V3=y
> CONFIG_NFS_V3_ACL=y
> CONFIG_NFS_V4=y
> CONFIG_NFS_DIRECTIO=y
>> CONFIG_NFSD=m
> CONFIG_NFSD_V2_ACL=y
> CONFIG_NFSD_V3=y
> CONFIG_NFSD_V3_ACL=y
> CONFIG_NFSD_V4=y
> CONFIG_NFSD_TCP=y
>> CONFIG_NFS_ACL_SUPPORT=m
> CONFIG_NFS_COMMON=y
> CONFIG_NCPFS_NFS_NS=y

> This is compiled with -mcmodel=kernel

No, on x86_64 it is, but not on UML, because UML has a bug (totally forgot 
this). After analisying deeply the bug (below) I checked this very basic 
assertion, and found that a patch is needed. Please recompile and retest 
without the patch (to make sure it's repeatable and not showing up randomly) 
and with the patch (to make sure it's a sufficient fix; without the first 
test this wouldn't be a perfect proof about patch validity). Do a make clean 
before the 1st compile (the one without the patch); kbuild is smart enough to 
recompile everything when it sees flags have changed.

Jeff, please merge this, after Jonathan response, even for 2.6.17-stable.

> [root@localhost ~]# service rpcidmapd start
> Starting RPC idmapd: [42949986.800000] overflow in
> relocation type 11 val 80b85e70 loc = 80b85e70
> [42949986.800000] `sunrpc' likely not compiled with
> FATAL: Error inserting sunrpc
> (/lib/modules/2.6.16.18/kernel/net/sunrpc/sunrpc.ko):
> Invalid module format
> FATAL: Error running install command for sunrpc

> I track this down and find the message comes from the kernel in

> ./arch/um/sys-x86_64/module.c
For what I can see here, that file is a symlink from x86_64 code.
>                case R_X86_64_32S:
>                        *(s32 *)loc = val;
>                        if ((s64)val != *(s32 *)loc)
>                                goto overflow;
>                        break;
>                case R_X86_64_PC32:
>                        val -= (u64)loc;
>                        *(u32 *)loc = val;
> #if 0
>                        if ((s64)val != *(s32 *)loc)
>                                goto overflow;
> #endif
>                        break;
>                default:
>                        printk(KERN_ERR "module %s: Unknown
> rela relocation: %Lu\n",
>                               me->name,
> ELF64_R_TYPE(rel[i].r_info));
>                        return -ENOEXEC;
>                }
>        }
>        return 0;
>
> overflow:
>        printk(KERN_ERR "overflow in relocation type %d val
> %Lx loc = %x\n",
>               (int)ELF64_R_TYPE(rel[i].r_info), val,*(u32
> *)loc);
You're wrong in printing loc as u32. It's a s32 value. However your analisys 
is correct.

>        printk(KERN_ERR "`%s' likely not compiled with
> -mcmodel=kernel\n",
>               me->name);
>        return -ENOEXEC;
> }
>
> Note I added to one printk so I could find out what actually
> is happening.
>
> Where R_X86_64_32S has the value 11,
>
>
> From the first error message printed on the console
>
> Starting RPC idmapd: [42949986.800000] overflow in
> relocation type 11 val 80b85e70 loc = 80b85e70
>
> Both loc and val are appear equal (one is a 64 bit signed
> and one is a 32 bit signed, one would be
> negative and one positive, and that why they are not equal)

Yes, the analisys seems almost correct. I.e. the positive but > 2G signed 
address kept in the 64bit var is converted to a negative one with the same 
representation. However, if the value is supposed to be an address it's very 
strange since 

> is this a bug, that only happens in uml?
It's not uml-only related as the code is x86_64.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

           reply	other threads:[~2006-06-25 15:56 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <E1FsiSR-0003HP-OO@sc8-sf-web5.sourceforge.net>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200606251755.45664.blaisorblade@yahoo.it \
    --to=blaisorblade@yahoo.it \
    --cc=jdike@addtoit.com \
    --cc=jtester@users.sourceforge.net \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox