Menu
▾
▴
user-mode-linux-user
|
From: enjoy m. <enj...@gm...> - 2014-05-30 07:29:45
|
Hi, all I build linux-3.12.6 uml with default configure. tar -jxf linux-3.12.6.tar.bz2 cd linux-3.12.6 make ARCH=um defconfig make ARCH=um linux I'm confused about the exception table of the uml kernel. $ objdump --full-contents --section=__ex_table linux linux: file format elf32-i386 Contents of section __ex_table: 82a5048 3e6fdcff bcbaf6ff 396fdcff b4baf6ff >o......9o...... 82a5058 336fdcff acbaf6ff 306fdcff bfbaf6ff 3o......0o...... 82a5068 2b6fdcff 9cbaf6ff 286fdcff afbaf6ff +o......(o...... 82a5078 236fdcff 8cbaf6ff 206fdcff 9fbaf6ff #o...... o...... 82a5088 1b6fdcff 7cbaf6ff 186fdcff 8fbaf6ff .o..|....o...... 82a5098 136fdcff 6cbaf6ff 106fdcff 7fbaf6ff .o..l....o...... 82a50a8 0b6fdcff 5cbaf6ff 086fdcff 6fbaf6ff .o..\....o..o... 82a50b8 036fdcff 4cbaf6ff 006fdcff 5fbaf6ff .o..L....o.._... 82a50c8 fb6edcff 3cbaf6ff f86edcff 4fbaf6ff .n..<....n..O... 82a50d8 f36edcff 2cbaf6ff f06edcff 3fbaf6ff .n..,....n..?... 82a50e8 eb6edcff 1cbaf6ff e86edcff 2fbaf6ff .n.......n../... 82a50f8 e36edcff 0cbaf6ff e06edcff 1fbaf6ff .n.......n...... 82a5108 db6edcff fcb9f6ff d86edcff 0fbaf6ff .n.......n...... 82a5118 d36edcff ecb9f6ff d06edcff ffb9f6ff .n.......n...... 82a5128 cb6edcff dcb9f6ff c86edcff efb9f6ff .n.......n...... 82a5138 c36edcff ccb9f6ff c06edcff dfb9f6ff .n.......n...... 82a5148 bb6edcff bcb9f6ff b86edcff cfb9f6ff .n.......n...... 82a5158 ce6edcff acb9f6ff cc6edcff bfb9f6ff .n.......n...... 82a5168 cf6edcff 9cb9f6ff c96edcff afb9f6ff .n.......n...... Let pick the first instruction location '3e6fdcff' (in human readable is 0xffdc6f3e). My question is how to find which function in UML kernel has an instruction in location 0xffdc6f3e? In i386 platform, the kernel address greater than the __PAGE_OFFSET (0xC0000000). However, as skas0 sperate the uml kernel and user process address space, it dose work by search address greater than the __PAGE_OFFSET for UML. thanks |
|
From: Richard W. <ric...@gm...> - 2014-05-30 07:45:34
|
On Fri, May 30, 2014 at 9:29 AM, enjoy mindful <enj...@gm...> wrote: > Hi, all > I build linux-3.12.6 uml with default configure. > > tar -jxf linux-3.12.6.tar.bz2 > cd linux-3.12.6 > make ARCH=um defconfig > make ARCH=um linux > > I'm confused about the exception table of the uml kernel. > > > $ objdump --full-contents --section=__ex_table linux > > linux: file format elf32-i386 > > Contents of section __ex_table: > 82a5048 3e6fdcff bcbaf6ff 396fdcff b4baf6ff >o......9o...... > 82a5058 336fdcff acbaf6ff 306fdcff bfbaf6ff 3o......0o...... > 82a5068 2b6fdcff 9cbaf6ff 286fdcff afbaf6ff +o......(o...... > 82a5078 236fdcff 8cbaf6ff 206fdcff 9fbaf6ff #o...... o...... > 82a5088 1b6fdcff 7cbaf6ff 186fdcff 8fbaf6ff .o..|....o...... > 82a5098 136fdcff 6cbaf6ff 106fdcff 7fbaf6ff .o..l....o...... > 82a50a8 0b6fdcff 5cbaf6ff 086fdcff 6fbaf6ff .o..\....o..o... > 82a50b8 036fdcff 4cbaf6ff 006fdcff 5fbaf6ff .o..L....o.._... > 82a50c8 fb6edcff 3cbaf6ff f86edcff 4fbaf6ff .n..<....n..O... > 82a50d8 f36edcff 2cbaf6ff f06edcff 3fbaf6ff .n..,....n..?... > 82a50e8 eb6edcff 1cbaf6ff e86edcff 2fbaf6ff .n.......n../... > 82a50f8 e36edcff 0cbaf6ff e06edcff 1fbaf6ff .n.......n...... > 82a5108 db6edcff fcb9f6ff d86edcff 0fbaf6ff .n.......n...... > 82a5118 d36edcff ecb9f6ff d06edcff ffb9f6ff .n.......n...... > 82a5128 cb6edcff dcb9f6ff c86edcff efb9f6ff .n.......n...... > 82a5138 c36edcff ccb9f6ff c06edcff dfb9f6ff .n.......n...... > 82a5148 bb6edcff bcb9f6ff b86edcff cfb9f6ff .n.......n...... > 82a5158 ce6edcff acb9f6ff cc6edcff bfb9f6ff .n.......n...... > 82a5168 cf6edcff 9cb9f6ff c96edcff afb9f6ff .n.......n...... > > Let pick the first instruction location '3e6fdcff' (in human readable > is 0xffdc6f3e). My question is how to find which function in UML > kernel has an instruction in location 0xffdc6f3e? Not sure whether I understand your question correctly. Isn't addr2line what you need? > > In i386 platform, the kernel address greater than the __PAGE_OFFSET > (0xC0000000). However, as skas0 sperate the uml kernel and user > process address space, it dose work by search address greater than the > __PAGE_OFFSET for UML. > > thanks > > ------------------------------------------------------------------------------ > Time is money. Stop wasting it! Get your web API in 5 minutes. > www.restlet.com/download > http://p.sf.net/sfu/restlet > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user -- Thanks, //richard |
|
From: enjoy m. <enj...@gm...> - 2014-05-30 08:08:56
|
Sorry. I know how to use addr2line. But it is not what I'm looking for. For example, with i386 kernel, it is easy to find c017e7a5 belong to function get_user. x86]$ vi /hack/linux-3.12.6/Documentation/x86/exception-tables.txt ............. 217 or in human readable byte order: 218 219 > c01aa7c4 c017c093 c0199fe0 c017c097 c017c099 ................ 220 > c01aa7d4 c017c2f6 c0199fe9 c017e7a5 c0199ff5 ................ 221 ^^^^^^^^^^^^^^^^^ 222 this is the interesting part! 223 > c01aa7e4 c0180a08 c019a001 c0180a0a c019a004 ................ my question is how to find 0xffdc6eb8 belong to which uml kernel function. thanks On Fri, May 30, 2014 at 3:45 PM, Richard Weinberger <ric...@gm...> wrote: > On Fri, May 30, 2014 at 9:29 AM, enjoy mindful <enj...@gm...> wrote: >> Hi, all >> I build linux-3.12.6 uml with default configure. >> >> tar -jxf linux-3.12.6.tar.bz2 >> cd linux-3.12.6 >> make ARCH=um defconfig >> make ARCH=um linux >> >> I'm confused about the exception table of the uml kernel. >> >> >> $ objdump --full-contents --section=__ex_table linux >> >> linux: file format elf32-i386 >> >> Contents of section __ex_table: >> 82a5048 3e6fdcff bcbaf6ff 396fdcff b4baf6ff >o......9o...... >> 82a5058 336fdcff acbaf6ff 306fdcff bfbaf6ff 3o......0o...... >> 82a5068 2b6fdcff 9cbaf6ff 286fdcff afbaf6ff +o......(o...... >> 82a5078 236fdcff 8cbaf6ff 206fdcff 9fbaf6ff #o...... o...... >> 82a5088 1b6fdcff 7cbaf6ff 186fdcff 8fbaf6ff .o..|....o...... >> 82a5098 136fdcff 6cbaf6ff 106fdcff 7fbaf6ff .o..l....o...... >> 82a50a8 0b6fdcff 5cbaf6ff 086fdcff 6fbaf6ff .o..\....o..o... >> 82a50b8 036fdcff 4cbaf6ff 006fdcff 5fbaf6ff .o..L....o.._... >> 82a50c8 fb6edcff 3cbaf6ff f86edcff 4fbaf6ff .n..<....n..O... >> 82a50d8 f36edcff 2cbaf6ff f06edcff 3fbaf6ff .n..,....n..?... >> 82a50e8 eb6edcff 1cbaf6ff e86edcff 2fbaf6ff .n.......n../... >> 82a50f8 e36edcff 0cbaf6ff e06edcff 1fbaf6ff .n.......n...... >> 82a5108 db6edcff fcb9f6ff d86edcff 0fbaf6ff .n.......n...... >> 82a5118 d36edcff ecb9f6ff d06edcff ffb9f6ff .n.......n...... >> 82a5128 cb6edcff dcb9f6ff c86edcff efb9f6ff .n.......n...... >> 82a5138 c36edcff ccb9f6ff c06edcff dfb9f6ff .n.......n...... >> 82a5148 bb6edcff bcb9f6ff b86edcff cfb9f6ff .n.......n...... >> 82a5158 ce6edcff acb9f6ff cc6edcff bfb9f6ff .n.......n...... >> 82a5168 cf6edcff 9cb9f6ff c96edcff afb9f6ff .n.......n...... >> >> Let pick the first instruction location '3e6fdcff' (in human readable >> is 0xffdc6f3e). My question is how to find which function in UML >> kernel has an instruction in location 0xffdc6f3e? > > Not sure whether I understand your question correctly. > Isn't addr2line what you need? > >> >> In i386 platform, the kernel address greater than the __PAGE_OFFSET >> (0xC0000000). However, as skas0 sperate the uml kernel and user >> process address space, it dose work by search address greater than the >> __PAGE_OFFSET for UML. >> >> thanks >> >> ------------------------------------------------------------------------------ >> Time is money. Stop wasting it! Get your web API in 5 minutes. >> www.restlet.com/download >> http://p.sf.net/sfu/restlet >> _______________________________________________ >> User-mode-linux-user mailing list >> Use...@li... >> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user > > > > -- > Thanks, > //richard |
|
From: Richard W. <ri...@no...> - 2014-05-30 08:51:09
|
Am 30.05.2014 10:08, schrieb enjoy mindful: > Sorry. I know how to use addr2line. But it is not what I'm looking for. > > For example, with i386 kernel, it is easy to find c017e7a5 belong to > function get_user. > > x86]$ vi /hack/linux-3.12.6/Documentation/x86/exception-tables.txt > ............. > 217 or in human readable byte order: > 218 > 219 > c01aa7c4 c017c093 c0199fe0 c017c097 c017c099 ................ > 220 > c01aa7d4 c017c2f6 c0199fe9 c017e7a5 c0199ff5 ................ > 221 ^^^^^^^^^^^^^^^^^ > 222 this is the interesting part! > 223 > c01aa7e4 c0180a08 c019a001 c0180a0a c019a004 ................ > > my question is how to find 0xffdc6eb8 belong to which uml kernel function. Ah ok. I'd decode it from the source side. I.e. start in arch/x86/um/fault.c Thanks, //richard |
|
From: Real N. <enj...@gm...> - 2014-06-04 13:39:19
|
On Fri, May 30, 2014 at 10:50:59AM +0200, Richard Weinberger wrote:
I find the function through checking which object file has the _ex_table section.
tmp]$ cat find_ex_table.sh
#!/bin/bash
(cd ~/uml/linux-3.12.6; find . -type f -name '*.o' > /tmp/xx.txt)
for file in `cat /tmp/xx.txt`; do
readelf -S ~/uml/linux-3.12.6/$file | grep ex_table
if [ $? -eq 0 ]; then
echo $file;
echo;
fi
done
All __extable entries belong to function csum_partial_copy_generic_i386 defined in file linux-3.12.6/arch/x86/um/checksum_32.S
However, I am confused with the difference between __ex_table of vmlinux.o and vmlinux(linux). To avoid mess the email, I only take two lines of the each objdump output.
-------------------------------------------------------------------------------
um]$ objdump --full-contents --section=__ex_table ~/uml/linux-3.12.6/vmlinux.o
/uml/linux-3.12.6/vmlinux.o: file format elf32-i386
Contents of section __ex_table:
0000 9e3d0100 00000000 a13d0100 00000000 .=.......=......
0010 a33d0100 00000000 a83d0100 1b000000 .=.......=......
-------------------------------------------------------------------------------
um]$ objdump --full-contents --section=__ex_table ~/uml/linux-3.12.6/vmlinux
uml/linux-3.12.6/vmlinux: file format elf32-i386
Contents of section __ex_table:
82a9048 b630dcff 14bcf6ff b130dcff 0cbcf6ff .0.......0......
82a9058 ab30dcff 04bcf6ff a830dcff 17bcf6ff .0.......0......
-------------------------------------------------------------------------------
Do you know, how to "9e3d0100" (vmlinx.o) become "b630dcff" (vmlinux), and the "00000000" (vmlinx.o) have been replaced with different values?
> Am 30.05.2014 10:08, schrieb enjoy mindful:
> > Sorry. I know how to use addr2line. But it is not what I'm looking for.
> >
> > For example, with i386 kernel, it is easy to find c017e7a5 belong to
> > function get_user.
> >
> > x86]$ vi /hack/linux-3.12.6/Documentation/x86/exception-tables.txt
> > .............
> > 217 or in human readable byte order:
> > 218
> > 219 > c01aa7c4 c017c093 c0199fe0 c017c097 c017c099 ................
> > 220 > c01aa7d4 c017c2f6 c0199fe9 c017e7a5 c0199ff5 ................
> > 221 ^^^^^^^^^^^^^^^^^
> > 222 this is the interesting part!
> > 223 > c01aa7e4 c0180a08 c019a001 c0180a0a c019a004 ................
> >
> > my question is how to find 0xffdc6eb8 belong to which uml kernel function.
>
> Ah ok.
> I'd decode it from the source side.
> I.e. start in arch/x86/um/fault.c
>
> Thanks,
> //richard
|
|
From: Richard W. <ri...@no...> - 2014-06-04 14:04:23
|
Am 04.06.2014 15:39, schrieb Real Name: > On Fri, May 30, 2014 at 10:50:59AM +0200, Richard Weinberger wrote: > > I find the function through checking which object file has the _ex_table section. > > tmp]$ cat find_ex_table.sh > #!/bin/bash > > (cd ~/uml/linux-3.12.6; find . -type f -name '*.o' > /tmp/xx.txt) > > for file in `cat /tmp/xx.txt`; do > readelf -S ~/uml/linux-3.12.6/$file | grep ex_table > if [ $? -eq 0 ]; then > echo $file; > echo; > fi > done > > All __extable entries belong to function csum_partial_copy_generic_i386 defined in file linux-3.12.6/arch/x86/um/checksum_32.S > I'm sure this is just because of copy&pasting from i386. I'd be surprised of exception tables actually work on UML. Thanks, //richard |
|
From: Honggang Li <enj...@gm...> - 2014-06-05 04:15:40
|
The csum_partial_copy_generic_i386 never been called. It mess up x86 uml kernel exception table. So remove it. linux-next]$ grep -n -r csum_partial_copy_generic_i386 . ./arch/x86/um/checksum_32.S:249:csum_partial_copy_generic_i386: ./arch/x86/um/checksum_32.S:384:csum_partial_copy_generic_i386: Honggang Li (1): remove csum_partial_copy_generic_i386 to clean up exception table arch/x86/um/checksum_32.S | 239 ---------------------------------------------- 1 file changed, 239 deletions(-) -- 1.8.3.1 |
|
From: Honggang Li <enj...@gm...> - 2014-06-05 04:15:43
|
arch/x86/um/checksum_32.S had been copy & paste from x86. When build x86 uml, csum_partial_copy_generic_i386 mess up the exception table. In fact, exception table dose not work in uml kernel. And csum_partial_copy_generic_i386 never been called. So, delete it. Signed-off-by: Honggang Li <enj...@gm...> --- arch/x86/um/checksum_32.S | 239 ---------------------------------------------- 1 file changed, 239 deletions(-) diff --git a/arch/x86/um/checksum_32.S b/arch/x86/um/checksum_32.S index 8d0c420..fa4b8b9 100644 --- a/arch/x86/um/checksum_32.S +++ b/arch/x86/um/checksum_32.S @@ -214,242 +214,3 @@ csum_partial: ret #endif - -/* -unsigned int csum_partial_copy_generic (const char *src, char *dst, - int len, int sum, int *src_err_ptr, int *dst_err_ptr) - */ - -/* - * Copy from ds while checksumming, otherwise like csum_partial - * - * The macros SRC and DST specify the type of access for the instruction. - * thus we can call a custom exception handler for all access types. - * - * FIXME: could someone double-check whether I haven't mixed up some SRC and - * DST definitions? It's damn hard to trigger all cases. I hope I got - * them all but there's no guarantee. - */ - -#define SRC(y...) \ - 9999: y; \ - _ASM_EXTABLE(9999b, 6001f) - -#define DST(y...) \ - 9999: y; \ - _ASM_EXTABLE(9999b, 6002f) - -.align 4 - -#ifndef CONFIG_X86_USE_PPRO_CHECKSUM - -#define ARGBASE 16 -#define FP 12 - -csum_partial_copy_generic_i386: - subl $4,%esp - pushl %edi - pushl %esi - pushl %ebx - movl ARGBASE+16(%esp),%eax # sum - movl ARGBASE+12(%esp),%ecx # len - movl ARGBASE+4(%esp),%esi # src - movl ARGBASE+8(%esp),%edi # dst - - testl $2, %edi # Check alignment. - jz 2f # Jump if alignment is ok. - subl $2, %ecx # Alignment uses up two bytes. - jae 1f # Jump if we had at least two bytes. - addl $2, %ecx # ecx was < 2. Deal with it. - jmp 4f -SRC(1: movw (%esi), %bx ) - addl $2, %esi -DST( movw %bx, (%edi) ) - addl $2, %edi - addw %bx, %ax - adcl $0, %eax -2: - movl %ecx, FP(%esp) - shrl $5, %ecx - jz 2f - testl %esi, %esi -SRC(1: movl (%esi), %ebx ) -SRC( movl 4(%esi), %edx ) - adcl %ebx, %eax -DST( movl %ebx, (%edi) ) - adcl %edx, %eax -DST( movl %edx, 4(%edi) ) - -SRC( movl 8(%esi), %ebx ) -SRC( movl 12(%esi), %edx ) - adcl %ebx, %eax -DST( movl %ebx, 8(%edi) ) - adcl %edx, %eax -DST( movl %edx, 12(%edi) ) - -SRC( movl 16(%esi), %ebx ) -SRC( movl 20(%esi), %edx ) - adcl %ebx, %eax -DST( movl %ebx, 16(%edi) ) - adcl %edx, %eax -DST( movl %edx, 20(%edi) ) - -SRC( movl 24(%esi), %ebx ) -SRC( movl 28(%esi), %edx ) - adcl %ebx, %eax -DST( movl %ebx, 24(%edi) ) - adcl %edx, %eax -DST( movl %edx, 28(%edi) ) - - lea 32(%esi), %esi - lea 32(%edi), %edi - dec %ecx - jne 1b - adcl $0, %eax -2: movl FP(%esp), %edx - movl %edx, %ecx - andl $0x1c, %edx - je 4f - shrl $2, %edx # This clears CF -SRC(3: movl (%esi), %ebx ) - adcl %ebx, %eax -DST( movl %ebx, (%edi) ) - lea 4(%esi), %esi - lea 4(%edi), %edi - dec %edx - jne 3b - adcl $0, %eax -4: andl $3, %ecx - jz 7f - cmpl $2, %ecx - jb 5f -SRC( movw (%esi), %cx ) - leal 2(%esi), %esi -DST( movw %cx, (%edi) ) - leal 2(%edi), %edi - je 6f - shll $16,%ecx -SRC(5: movb (%esi), %cl ) -DST( movb %cl, (%edi) ) -6: addl %ecx, %eax - adcl $0, %eax -7: -5000: - -# Exception handler: -.section .fixup, "ax" - -6001: - movl ARGBASE+20(%esp), %ebx # src_err_ptr - movl $-EFAULT, (%ebx) - - # zero the complete destination - computing the rest - # is too much work - movl ARGBASE+8(%esp), %edi # dst - movl ARGBASE+12(%esp), %ecx # len - xorl %eax,%eax - rep ; stosb - - jmp 5000b - -6002: - movl ARGBASE+24(%esp), %ebx # dst_err_ptr - movl $-EFAULT,(%ebx) - jmp 5000b - -.previous - - popl %ebx - popl %esi - popl %edi - popl %ecx # equivalent to addl $4,%esp - ret - -#else - -/* Version for PentiumII/PPro */ - -#define ROUND1(x) \ - SRC(movl x(%esi), %ebx ) ; \ - addl %ebx, %eax ; \ - DST(movl %ebx, x(%edi) ) ; - -#define ROUND(x) \ - SRC(movl x(%esi), %ebx ) ; \ - adcl %ebx, %eax ; \ - DST(movl %ebx, x(%edi) ) ; - -#define ARGBASE 12 - -csum_partial_copy_generic_i386: - pushl %ebx - pushl %edi - pushl %esi - movl ARGBASE+4(%esp),%esi #src - movl ARGBASE+8(%esp),%edi #dst - movl ARGBASE+12(%esp),%ecx #len - movl ARGBASE+16(%esp),%eax #sum -# movl %ecx, %edx - movl %ecx, %ebx - movl %esi, %edx - shrl $6, %ecx - andl $0x3c, %ebx - negl %ebx - subl %ebx, %esi - subl %ebx, %edi - lea -1(%esi),%edx - andl $-32,%edx - lea 3f(%ebx,%ebx), %ebx - testl %esi, %esi - jmp *%ebx -1: addl $64,%esi - addl $64,%edi - SRC(movb -32(%edx),%bl) ; SRC(movb (%edx),%bl) - ROUND1(-64) ROUND(-60) ROUND(-56) ROUND(-52) - ROUND (-48) ROUND(-44) ROUND(-40) ROUND(-36) - ROUND (-32) ROUND(-28) ROUND(-24) ROUND(-20) - ROUND (-16) ROUND(-12) ROUND(-8) ROUND(-4) -3: adcl $0,%eax - addl $64, %edx - dec %ecx - jge 1b -4: movl ARGBASE+12(%esp),%edx #len - andl $3, %edx - jz 7f - cmpl $2, %edx - jb 5f -SRC( movw (%esi), %dx ) - leal 2(%esi), %esi -DST( movw %dx, (%edi) ) - leal 2(%edi), %edi - je 6f - shll $16,%edx -5: -SRC( movb (%esi), %dl ) -DST( movb %dl, (%edi) ) -6: addl %edx, %eax - adcl $0, %eax -7: -.section .fixup, "ax" -6001: movl ARGBASE+20(%esp), %ebx # src_err_ptr - movl $-EFAULT, (%ebx) - # zero the complete destination (computing the rest is too much work) - movl ARGBASE+8(%esp),%edi # dst - movl ARGBASE+12(%esp),%ecx # len - xorl %eax,%eax - rep; stosb - jmp 7b -6002: movl ARGBASE+24(%esp), %ebx # dst_err_ptr - movl $-EFAULT, (%ebx) - jmp 7b -.previous - - popl %esi - popl %edi - popl %ebx - ret - -#undef ROUND -#undef ROUND1 - -#endif -- 1.8.3.1 |
|
From: Richard W. <ri...@no...> - 2014-06-05 21:50:02
|
Am 05.06.2014 06:15, schrieb Honggang Li:
> arch/x86/um/checksum_32.S had been copy & paste from x86. When build
> x86 uml, csum_partial_copy_generic_i386 mess up the exception table.
> In fact, exception table dose not work in uml kernel.
Are you sure that exception tables do not work on UML?
I said, I'm not sure. Can you please find out?
In arch/um/kernel/trap.c:segv() we have the mechanism for it:
else if (!is_user && arch_fixup(ip, regs))
goto out;
The interesting question is, is this by design or was it just copy&pasted from x86
many moons ago? :)
> And csum_partial_copy_generic_i386 never been called. So, delete it.
I like such clean ups. :-)
Thanks,
//richard
|
|
From: Real N. <enj...@gm...> - 2014-06-09 05:46:10
Attachments:
0001-uml-remove-csum_partial_copy_generic_i386.patch
|
On Thu, Jun 05, 2014 at 11:49:49PM +0200, Richard Weinberger wrote: > Am 05.06.2014 06:15, schrieb Honggang Li: > > arch/x86/um/checksum_32.S had been copy & paste from x86. When build > > x86 uml, csum_partial_copy_generic_i386 mess up the exception table. > > In fact, exception table dose not work in uml kernel. > > Are you sure that exception tables do not work on UML? > I said, I'm not sure. Can you please find out? I think we can't test the exception table with linux-next uml kernel, because the exception table is broken. The *old* linux-2.4.xx uml kernel has a good exception table. 1) install one redhat-9.0 virtual machine 2) build and booting into linux-2.4.25. You can't run uml kernel with default redhat-9.0 kernel, because there is one bug. 3) build linux-2.4.20 uml kernel (with uml-patch-2.4.20-8) 4) run linux-2.4.20/linux ubda=/root/root_fs.rh-7.2-server.pristine.20020312 mem=64m (The root_fs and uml-patch are available from the *old* uml website.) The exception table records of the old kernel belong to csum_partial_copy_generic_i386 too. # objjdump --full-contents --section=__ex_table arch/um/sys-i386/checksum.o arch/um/sys-i386/checksum.o: file format elf32-i386 Contents of section __ex_table: 0000 c7000000 00000000 cd000000 1b000000 ................ 0010 e4000000 00000000 e6000000 00000000 ................ 0020 eb000000 1b000000 ef000000 1b000000 ................ 0030 f2000000 00000000 f5000000 00000000 ................ 0040 fa000000 1b000000 ff000000 1b000000 ................ 0050 02010000 00000000 05010000 00000000 ................ 0060 0a010000 1b000000 0f010000 1b000000 ................ 0070 12010000 00000000 15010000 00000000 ................ 0080 1a010000 1b000000 1f010000 1b000000 ................ 0090 3c010000 00000000 40010000 1b000000 <.......@....... 00a0 58010000 00000000 5e010000 1b000000 X.......^....... 00b0 69010000 00000000 6b010000 1b000000 i.......k...... [root@rht9 linux-2.4.20]# objdump --full-contents --section=__ex_table arch/um/kern> arch/um/kernel/checksum.o: file format elf32-i386 [root@rht9 linux-2.4.20]# objdump --full-contents --section=__ex_table linux linux: file format elf32-i386 Contents of section __ex_table: a0203c20 5b680ea0 2cd31ba0 61680ea0 47d31ba0 [h..,...ah..G... a0203c30 78680ea0 2cd31ba0 7a680ea0 2cd31ba0 xh..,...zh..,... a0203c40 7f680ea0 47d31ba0 83680ea0 47d31ba0 .h..G....h..G... a0203c50 86680ea0 2cd31ba0 89680ea0 2cd31ba0 .h..,....h..,... a0203c60 8e680ea0 47d31ba0 93680ea0 47d31ba0 .h..G....h..G... a0203c70 96680ea0 2cd31ba0 99680ea0 2cd31ba0 .h..,....h..,... a0203c80 9e680ea0 47d31ba0 a3680ea0 47d31ba0 .h..G....h..G... a0203c90 a6680ea0 2cd31ba0 a9680ea0 2cd31ba0 .h..,....h..,... a0203ca0 ae680ea0 47d31ba0 b3680ea0 47d31ba0 .h..G....h..G... a0203cb0 d0680ea0 2cd31ba0 d4680ea0 47d31ba0 .h..,....h..G... a0203cc0 ec680ea0 2cd31ba0 f2680ea0 47d31ba0 .h..,....h..G... a0203cd0 fd680ea0 2cd31ba0 ff680ea0 47d31ba0 .h..,....h..G... ************************************************************************** The exception table of linux-3.1x.y is broken. The complier tool chain create bad exception table. I think this should be a bug. linux-3.12.6]$ objdump --full-contents --section=__ex_table ./linux ./linux: file format elf32-i386 Contents of section __ex_table: 82a5048 3e6fdcff bcbaf6ff 396fdcff b4baf6ff >o......9o...... 82a5058 336fdcff acbaf6ff 306fdcff bfbaf6ff 3o......0o...... 82a5068 2b6fdcff 9cbaf6ff 286fdcff afbaf6ff +o......(o...... 82a5078 236fdcff 8cbaf6ff 206fdcff 9fbaf6ff #o...... o...... 82a5088 1b6fdcff 7cbaf6ff 186fdcff 8fbaf6ff .o..|....o...... 82a5098 136fdcff 6cbaf6ff 106fdcff 7fbaf6ff .o..l....o...... 82a50a8 0b6fdcff 5cbaf6ff 086fdcff 6fbaf6ff .o..\....o..o... 82a50b8 036fdcff 4cbaf6ff 006fdcff 5fbaf6ff .o..L....o.._... 82a50c8 fb6edcff 3cbaf6ff f86edcff 4fbaf6ff .n..<....n..O... 82a50d8 f36edcff 2cbaf6ff f06edcff 3fbaf6ff .n..,....n..?... 82a50e8 eb6edcff 1cbaf6ff e86edcff 2fbaf6ff .n.......n../... 82a50f8 e36edcff 0cbaf6ff e06edcff 1fbaf6ff .n.......n...... 82a5108 db6edcff fcb9f6ff d86edcff 0fbaf6ff .n.......n...... 82a5118 d36edcff ecb9f6ff d06edcff ffb9f6ff .n.......n...... 82a5128 cb6edcff dcb9f6ff c86edcff efb9f6ff .n.......n...... 82a5138 c36edcff ccb9f6ff c06edcff dfb9f6ff .n.......n...... 82a5148 bb6edcff bcb9f6ff b86edcff cfb9f6ff .n.......n...... 82a5158 ce6edcff acb9f6ff cc6edcff bfb9f6ff .n.......n...... 82a5168 cf6edcff 9cb9f6ff c96edcff afb9f6ff .n.......n...... > > In arch/um/kernel/trap.c:segv() we have the mechanism for it: > else if (!is_user && arch_fixup(ip, regs)) > goto out; > The kcov analysis proof that this piece of code never been executed. > The interesting question is, is this by design or was it just copy&pasted from x86 > many moons ago? :) Hi, Jeff Could you please answer this question, as you are the author? thanks > > > And csum_partial_copy_generic_i386 never been called. So, delete it. > > I like such clean ups. :-) Could you please pick up the attached patch. I update the comment of the patch. Thank you. > > Thanks, > //richard |
|
From: Real N. <enj...@gm...> - 2014-06-17 13:45:18
|
On Mon, Jun 09, 2014 at 01:45:56PM +0800, Real Name wrote:
> On Thu, Jun 05, 2014 at 11:49:49PM +0200, Richard Weinberger wrote:
> > Am 05.06.2014 06:15, schrieb Honggang Li:
> > > arch/x86/um/checksum_32.S had been copy & paste from x86. When build
> > > x86 uml, csum_partial_copy_generic_i386 mess up the exception table.
> > > In fact, exception table dose not work in uml kernel.
> >
> > Are you sure that exception tables do not work on UML?
> > I said, I'm not sure. Can you please find out?
>
> I think we can't test the exception table with linux-next uml kernel, because
> the exception table is broken.
>
This patch is the root source of the broken exception table of UML
kernel.
linux]# git bisect visualize
commit 706276543b699d80f546e45f8b12574e7b18d952
Author: H. Peter Anvin <hp...@zy...>
Date: Fri Apr 20 17:12:48 2012 -0700
x86, extable: Switch to relative exception table entries
|
|
From: Real N. <enj...@gm...> - 2014-06-21 07:29:07
|
On Thu, Jun 05, 2014 at 11:49:49PM +0200, Richard Weinberger wrote: > Am 05.06.2014 06:15, schrieb Honggang Li: > > arch/x86/um/checksum_32.S had been copy & paste from x86. When build > > x86 uml, csum_partial_copy_generic_i386 mess up the exception table. > > In fact, exception table dose not work in uml kernel. > > Are you sure that exception tables do not work on UML? > I said, I'm not sure. Can you please find out? Hi, After traced i386 uml kernel with gdb , I'm sure exception tables do *not* work. When csum_partial_copy_generic_i386 read user space memory, an access error exception arises, however, the segv function always return zero. So, the fixup nerver executed. The uml system hang (not kernel panic). thanks. > > In arch/um/kernel/trap.c:segv() we have the mechanism for it: > else if (!is_user && arch_fixup(ip, regs)) > goto out; > > The interesting question is, is this by design or was it just copy&pasted from x86 > many moons ago? :) > > > And csum_partial_copy_generic_i386 never been called. So, delete it. > > I like such clean ups. :-) > > Thanks, > //richard |
|
From: Real N. <enj...@gm...> - 2014-06-28 04:06:42
|
On Sat, Jun 21, 2014 at 03:28:52PM +0800, Real Name wrote:
> On Thu, Jun 05, 2014 at 11:49:49PM +0200, Richard Weinberger wrote:
> > Am 05.06.2014 06:15, schrieb Honggang Li:
> > > arch/x86/um/checksum_32.S had been copy & paste from x86. When build
> > > x86 uml, csum_partial_copy_generic_i386 mess up the exception table.
> > > In fact, exception table dose not work in uml kernel.
> >
> > Are you sure that exception tables do not work on UML?
> > I said, I'm not sure. Can you please find out?
>
> Hi,
> After traced i386 uml kernel with gdb , I'm sure exception tables
> do *not* work. When csum_partial_copy_generic_i386 read user space memory,
> an access error exception arises, however, the segv function always
> return zero. So, the fixup nerver executed. The uml system hang (not
> kernel panic).
The kernel hang because the SEGV signal handler can't modify the EIP
register in signal context.
Here is the summary why exception table dose not works for linux (>3.3):
1) broken exception table (706276543b699d80f546e45f8b12574e7b18d952)
2) arch_fixup modify the local copy of regs.
>
> thanks.
>
> >
> > In arch/um/kernel/trap.c:segv() we have the mechanism for it:
> > else if (!is_user && arch_fixup(ip, regs))
> > goto out;
0) access invalid memory address in kernel (no mm for the address. it is
easy to force invalid memory acess in kernel. I cast 0x1234 as a void
pointer, and pass it to csum_partial_copy_generic_i386)
1) SEGV signal arise
1.1) hard_handler (arch/um/os-Linux/signal.c)
The third argument of hard_handler point to signal context.
1.2) call sig_handler
1.3) call sig_handler_common (dump the registers in signal context into
local var struct uml_pt_regs r.). line 36 is the key point why
exception table dose not works in UML.
34 if (sig == SIGSEGV) {
35 /* For segfaults, we want the data from the sigcontext. */
36 get_regs_from_mc(&r, mc);
37 GET_FAULTINFO_FROM_MC(r.faultinfo, mc);
38
1.4) call segv_handler (arch/um/kernel/trap.c)
1.5) call segv
1.6) call arch_fixup (arch/x86/um/fault.c)
1.7) arch_fixup (UPT_IP(regs) = fixup->fixup;) set the EIP register of
local copy uml_pt_regs
1.8) When function return to sig_handler, the EIP change lost
1.9) When hard_handler signal handler return, it restore the EIP with
the address arise the SEGV in step 0. The fixup section never be
executed. If exception table works, UML kernel should run fixup code in
here.
Then repeate step 0 to 1.9, kernel hang on.
thanks
> >
> > The interesting question is, is this by design or was it just copy&pasted from x86
> > many moons ago? :)
> >
> > > And csum_partial_copy_generic_i386 never been called. So, delete it.
> >
> > I like such clean ups. :-)
> >
> > Thanks,
> > //richard
|
|
From: Real N. <enj...@gm...> - 2014-07-17 23:13:42
|
On Sat, Jun 28, 2014 at 12:06:28PM +0800, Real Name wrote:
> On Sat, Jun 21, 2014 at 03:28:52PM +0800, Real Name wrote:
> > On Thu, Jun 05, 2014 at 11:49:49PM +0200, Richard Weinberger wrote:
> > > Am 05.06.2014 06:15, schrieb Honggang Li:
> > > > arch/x86/um/checksum_32.S had been copy & paste from x86. When build
> > > > x86 uml, csum_partial_copy_generic_i386 mess up the exception table.
> > > > In fact, exception table dose not work in uml kernel.
> > >
> > > Are you sure that exception tables do not work on UML?
> > > I said, I'm not sure. Can you please find out?
> >
> > Hi,
> > After traced i386 uml kernel with gdb , I'm sure exception tables
> > do *not* work. When csum_partial_copy_generic_i386 read user space memory,
> > an access error exception arises, however, the segv function always
> > return zero. So, the fixup nerver executed. The uml system hang (not
> > kernel panic).
>
> The kernel hang because the SEGV signal handler can't modify the EIP
> register in signal context.
>
> Here is the summary why exception table dose not works for linux (>3.3):
> 1) broken exception table (706276543b699d80f546e45f8b12574e7b18d952)
> 2) arch_fixup modify the local copy of regs.
hi, Richard
ping? are you agree with what i said?
> >
> > thanks.
> >
> > >
> > > In arch/um/kernel/trap.c:segv() we have the mechanism for it:
> > > else if (!is_user && arch_fixup(ip, regs))
> > > goto out;
> 0) access invalid memory address in kernel (no mm for the address. it is
> easy to force invalid memory acess in kernel. I cast 0x1234 as a void
> pointer, and pass it to csum_partial_copy_generic_i386)
> 1) SEGV signal arise
> 1.1) hard_handler (arch/um/os-Linux/signal.c)
> The third argument of hard_handler point to signal context.
> 1.2) call sig_handler
> 1.3) call sig_handler_common (dump the registers in signal context into
> local var struct uml_pt_regs r.). line 36 is the key point why
> exception table dose not works in UML.
>
> 34 if (sig == SIGSEGV) {
> 35 /* For segfaults, we want the data from the sigcontext. */
> 36 get_regs_from_mc(&r, mc);
> 37 GET_FAULTINFO_FROM_MC(r.faultinfo, mc);
> 38
>
> 1.4) call segv_handler (arch/um/kernel/trap.c)
> 1.5) call segv
> 1.6) call arch_fixup (arch/x86/um/fault.c)
> 1.7) arch_fixup (UPT_IP(regs) = fixup->fixup;) set the EIP register of
> local copy uml_pt_regs
> 1.8) When function return to sig_handler, the EIP change lost
> 1.9) When hard_handler signal handler return, it restore the EIP with
> the address arise the SEGV in step 0. The fixup section never be
> executed. If exception table works, UML kernel should run fixup code in
> here.
>
> Then repeate step 0 to 1.9, kernel hang on.
>
> thanks
>
> > >
> > > The interesting question is, is this by design or was it just copy&pasted from x86
> > > many moons ago? :)
> > >
> > > > And csum_partial_copy_generic_i386 never been called. So, delete it.
> > >
> > > I like such clean ups. :-)
> > >
> > > Thanks,
> > > //richard
|
|
From: Richard W. <ri...@no...> - 2014-07-18 07:34:17
|
Am 18.07.2014 01:13, schrieb Real Name:
> On Sat, Jun 28, 2014 at 12:06:28PM +0800, Real Name wrote:
>> On Sat, Jun 21, 2014 at 03:28:52PM +0800, Real Name wrote:
>>> On Thu, Jun 05, 2014 at 11:49:49PM +0200, Richard Weinberger wrote:
>>>> Am 05.06.2014 06:15, schrieb Honggang Li:
>>>>> arch/x86/um/checksum_32.S had been copy & paste from x86. When build
>>>>> x86 uml, csum_partial_copy_generic_i386 mess up the exception table.
>>>>> In fact, exception table dose not work in uml kernel.
>>>>
>>>> Are you sure that exception tables do not work on UML?
>>>> I said, I'm not sure. Can you please find out?
>>>
>>> Hi,
>>> After traced i386 uml kernel with gdb , I'm sure exception tables
>>> do *not* work. When csum_partial_copy_generic_i386 read user space memory,
>>> an access error exception arises, however, the segv function always
>>> return zero. So, the fixup nerver executed. The uml system hang (not
>>> kernel panic).
>>
>> The kernel hang because the SEGV signal handler can't modify the EIP
>> register in signal context.
>>
>> Here is the summary why exception table dose not works for linux (>3.3):
>> 1) broken exception table (706276543b699d80f546e45f8b12574e7b18d952)
>> 2) arch_fixup modify the local copy of regs.
>
> hi, Richard
> ping? are you agree with what i said?
>
Yeah, I think we can merge both of your patches in 3.17. :)
Thanks,
//richard
>>>
>>> thanks.
>>>
>>>>
>>>> In arch/um/kernel/trap.c:segv() we have the mechanism for it:
>>>> else if (!is_user && arch_fixup(ip, regs))
>>>> goto out;
>> 0) access invalid memory address in kernel (no mm for the address. it is
>> easy to force invalid memory acess in kernel. I cast 0x1234 as a void
>> pointer, and pass it to csum_partial_copy_generic_i386)
>> 1) SEGV signal arise
>> 1.1) hard_handler (arch/um/os-Linux/signal.c)
>> The third argument of hard_handler point to signal context.
>> 1.2) call sig_handler
>> 1.3) call sig_handler_common (dump the registers in signal context into
>> local var struct uml_pt_regs r.). line 36 is the key point why
>> exception table dose not works in UML.
>>
>> 34 if (sig == SIGSEGV) {
>> 35 /* For segfaults, we want the data from the sigcontext. */
>> 36 get_regs_from_mc(&r, mc);
>> 37 GET_FAULTINFO_FROM_MC(r.faultinfo, mc);
>> 38
>>
>> 1.4) call segv_handler (arch/um/kernel/trap.c)
>> 1.5) call segv
>> 1.6) call arch_fixup (arch/x86/um/fault.c)
>> 1.7) arch_fixup (UPT_IP(regs) = fixup->fixup;) set the EIP register of
>> local copy uml_pt_regs
>> 1.8) When function return to sig_handler, the EIP change lost
>> 1.9) When hard_handler signal handler return, it restore the EIP with
>> the address arise the SEGV in step 0. The fixup section never be
>> executed. If exception table works, UML kernel should run fixup code in
>> here.
>>
>> Then repeate step 0 to 1.9, kernel hang on.
>>
>> thanks
>>
>>>>
>>>> The interesting question is, is this by design or was it just copy&pasted from x86
>>>> many moons ago? :)
>>>>
>>>>> And csum_partial_copy_generic_i386 never been called. So, delete it.
>>>>
>>>> I like such clean ups. :-)
>>>>
>>>> Thanks,
>>>> //richard
|
Thanks for helping keep SourceForge clean.
X