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
parent 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