yeah I talked to barrett about this one and it seems D is not set. Would have been nice!
ron On Wed, Dec 9, 2015 at 4:39 PM 'Davide Libenzi' via Akaros < [email protected]> wrote: > No sorry, wrong nibble ☺ > D seems not set at that point at least. > > > On Wed, Dec 9, 2015 at 4:31 PM, Davide Libenzi <[email protected]> > wrote: > >> If RFL= is EFLAGS, than RFL=00000246 means 'D' flag (bit 10) is set. >> Wrong direction 😐 >> >> >> On Wed, Dec 9, 2015 at 4:20 PM, Davide Libenzi <[email protected]> >> wrote: >> >>> diff --git a/kern/arch/x86/uaccess.h b/kern/arch/x86/uaccess.h >>> index 6beea33..0752b4b 100644 >>> --- a/kern/arch/x86/uaccess.h >>> +++ b/kern/arch/x86/uaccess.h >>> @@ -87,6 +87,7 @@ struct extable_ip_fixup { >>> >>> #define __user_memcpy(dst, src, count, err, errret) \ >>> asm volatile(ASM_STAC "\n" \ >>> + "cld\n" \ >>> "1: rep movsb\n" \ >>> "2: " ASM_CLAC "\n" \ >>> ".section .fixup,\"ax\"\n" \ >>> >>> >>> On Wed, Dec 9, 2015 at 4:17 PM, Davide Libenzi <[email protected]> >>> wrote: >>> >>>> Maybe some kernel code stuck the direction flag to STD. >>>> Maybe better drop a CLD in there. .. >>>> >>>> >>>> On Wed, Dec 9, 2015 at 4:16 PM, Davide Libenzi <[email protected]> >>>> wrote: >>>> >>>>> Are we using the proper direction? 😀 >>>>> As in, CLD/STD ... >>>>> >>>>> >>>>> On Wed, Dec 9, 2015 at 4:10 PM, ron minnich <[email protected]> >>>>> wrote: >>>>> >>>>>> I can imagine a case where the address you're using as the source is >>>>>> not pointing where you think it is. I've had that problem >>>>>> from time to time. >>>>>> >>>>>> On Wed, Dec 9, 2015 at 4:05 PM Barret Rhoden <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> So here's a nasty bug of some sort. >>>>>>> >>>>>>> I'm in the middle of doing some changes to backtrace, so we can >>>>>>> easily >>>>>>> output user backtraces. In the process, I started running into an >>>>>>> issue where the backtrace wouldn't make progress, and would stick on >>>>>>> the second entry in the BT. it doesn't always happen either. >>>>>>> >>>>>>> I narrowed it down to these instructions (hacked up a bit, nops and >>>>>>> whatnot). >>>>>>> >>>>>>> ffffffffc2100081: b9 10 00 00 00 mov $0x10,%ecx >>>>>>> ffffffffc2100086: 90 nop >>>>>>> ffffffffc2100087: 90 nop >>>>>>> ffffffffc2100088: 90 nop >>>>>>> ffffffffc2100089: 45 31 c0 xor %r8d,%r8d >>>>>>> ffffffffc210008c: 4c 89 e7 mov %r12,%rdi >>>>>>> ffffffffc210008f: 4c 89 fe mov %r15,%rsi >>>>>>> ffffffffc2100092: f3 a4 rep movsb >>>>>>> %ds:(%rsi),%es:(%rdi) >>>>>>> ffffffffc2100094: 90 nop >>>>>>> ffffffffc2100095: 90 nop >>>>>>> ffffffffc2100096: 90 nop >>>>>>> ffffffffc2100097: 4c 8b 4d c0 mov -0x40(%rbp),%r9 >>>>>>> ffffffffc210009b: 4d 39 f9 cmp %r15,%r9 >>>>>>> ffffffffc210009e: 74 30 je ffffffffc21000d0 >>>>>>> <backtrace_user_list+0x80> >>>>>>> >>>>>>> >>>>>>> that last bit is a jump to a while(1) loop, so i can look at things >>>>>>> in >>>>>>> qemu. the check was whether or not some stack variable changed >>>>>>> (which >>>>>>> we copied into), its addr is rdi == r12. the value should change >>>>>>> (based on the program). and when we look at the state of the >>>>>>> machine, >>>>>>> it's not clear why it didn't. other than r9 and flags from the cmp, >>>>>>> our state should be the same as it was right after the rep movsb. >>>>>>> >>>>>>> (qemu) info registers >>>>>>> RAX=ffff80013eb5adf0 RBX=0000000000000001 RCX=0000000000000000 >>>>>>> RDX=ffff80013eb5adf0 >>>>>>> RSI=00007f7fffbfef50 RDI=ffff80013eb5ada0 RBP=ffff80013eb5ade0 >>>>>>> RSP=ffff80013eb5ad80 >>>>>>> R8 =0000000000000000 R9 =00007f7fffbfef50 R10=ffff8000000b8f00 >>>>>>> R11=ffff8000000b8ec0 >>>>>>> R12=ffff80013eb5ada0 R13=0000000000000014 R14=0000000000401a86 >>>>>>> R15=00007f7fffbfef50 >>>>>>> RIP=ffffffffc21000d0 RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 >>>>>>> HLT=0 >>>>>>> ES =0000 0000000000000000 ffffffff 00c00000 >>>>>>> CS =0008 0000000000000000 00000000 00209900 DPL=0 CS64 [--A] >>>>>>> SS =0000 0000000000000000 ffffffff 00c00000 >>>>>>> DS =0000 0000000000000000 ffffffff 00c00000 >>>>>>> FS =0000 00004000005d90c0 ffffffff 00c00000 >>>>>>> GS =0000 ffffffffc6c8b7c0 ffffffff 00c00000 >>>>>>> LDT=0000 0000000000000000 ffffffff 00c00000 >>>>>>> TR =0028 ffffffffc6db4380 00000068 00008b00 DPL=0 TSS64-busy >>>>>>> GDT= ffff800000101000 00000037 >>>>>>> IDT= ffffffffc6c89f10 00000fff >>>>>>> CR0=80010033 CR2=000000000061d000 CR3=000000013ecca000 CR4=000007b0 >>>>>>> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 >>>>>>> DR3=0000000000000000 >>>>>>> DR6=00000000ffff0ff0 DR7=0000000000000400 >>>>>>> EFER=0000000000000501 >>>>>>> FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 >>>>>>> FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 >>>>>>> FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 >>>>>>> FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 >>>>>>> FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 >>>>>>> XMM00=0000000000000000ff00000000000000 >>>>>>> XMM01=25252525252525252525252525252525 >>>>>>> XMM02=00000000000000000000000000000000 >>>>>>> XMM03=00000000000000000000000000000000 >>>>>>> XMM04=0000000000000000ff00000000000000 >>>>>>> XMM05=00000000000000000000000000000000 >>>>>>> XMM06=00000000000000000000000000000000 >>>>>>> XMM07=00000000000000000000000000000000 >>>>>>> XMM08=00000000000000000000000000000000 >>>>>>> XMM09=ffffffffffffff00ffffffffffffff00 >>>>>>> XMM10=ffffffffffffff00ffffffffffffff00 >>>>>>> XMM11=ffffffffffffffffffffffffffffff00 >>>>>>> XMM12=00000000000000000000000000000000 >>>>>>> XMM13=00000000000000000000000000000000 >>>>>>> XMM14=00000000000000000000000000000000 >>>>>>> XMM15=00000000000000000000000000000000 >>>>>>> >>>>>>> note that : >>>>>>> >>>>>>> RDI = R12 = the destination of the rep movsb. >>>>>>> RSI = R15 = the source of the rep movsb >>>>>>> RCX = 0 (it was 16), meaning that we did our reps. >>>>>>> >>>>>>> Here's the destination hexdump: >>>>>>> (qemu) x /32wx 0xffff80013eb5ada0 >>>>>>> ffff80013eb5ada0: 0xffbfef50 0x00007f7f 0x00401a86 0x00000000 >>>>>>> ffff80013eb5adb0: 0x3eb5ade0 0xffff8001 0x00000000 0x00000000 >>>>>>> ffff80013eb5adc0: 0x00000000 0x00000000 0x3eb5af40 0xffff8001 >>>>>>> ffff80013eb5add0: 0xc6c8b7c0 0xffffffff 0x00401990 0x00000000 >>>>>>> ffff80013eb5ade0: 0x3eb5aeb0 0xffff8001 0xc200d341 0xffffffff >>>>>>> ffff80013eb5adf0: 0x00402f59 0x00000000 0x00000000 0x00000000 >>>>>>> ffff80013eb5ae00: 0x80000001 0x00000000 0x3eb5af40 0xffff8001 >>>>>>> ffff80013eb5ae10: 0x000003d4 0x00000000 0x00003ab1 0x00000000 >>>>>>> >>>>>>> Here's the source hexdump: >>>>>>> (qemu) x /32wx 0x00007f7fffbfef50 >>>>>>> 00007f7fffbfef50: 0x00000000 0x00000000 0x004020c1 0x00000000 >>>>>>> 00007f7fffbfef60: 0xffbfef68 0x00007f7f 0x0000001c 0x00000000 >>>>>>> 00007f7fffbfef70: 0x00000001 0x00000000 0xffbfefe8 0x00007f7f >>>>>>> 00007f7fffbfef80: 0x00000000 0x00000000 0xffbfeff5 0x00007f7f >>>>>>> 00007f7fffbfef90: 0x00000000 0x00000000 0x00000003 0x00000000 >>>>>>> 00007f7fffbfefa0: 0x00400040 0x00000000 0x00000004 0x00000000 >>>>>>> 00007f7fffbfefb0: 0x00000020 0x00000000 0x00000005 0x00000000 >>>>>>> 00007f7fffbfefc0: 0x00000009 0x00000000 0x00000009 0x00000000 >>>>>>> >>>>>>> >>>>>>> the first 16 bytes should be the same. had we actually copied the >>>>>>> src >>>>>>> into the dst, then the program (backtrace) would work. but it looks >>>>>>> like we just silently ignored it. >>>>>>> >>>>>>> note this is a hacked up copy_from_user(), where it is just a >>>>>>> __user_memcpy(), which is what happens when you do a count of say 16 >>>>>>> bytes (in this case). >>>>>>> >>>>>>> you can see from r8 == 0 that there was no error. i also had a >>>>>>> printk >>>>>>> in the try_exception_fixup just in case. >>>>>>> >>>>>>> does anyone know of a reason why rep movsb might not work? it sounds >>>>>>> crazy. (i also tested on hardware, and it seems to do the same, >>>>>>> though >>>>>>> i can't inspect the state easily). >>>>>>> >>>>>>> likewise, there's probably something i'm doing wrong. also note that >>>>>>> this code runs from IRQ context (CTRL-B backspace). >>>>>>> >>>>>>> a super-nasty commit with all of my debugging crap is at >>>>>>> origin/nasty-bug if anyone wants to take a look. (i also do an ash >>>>>>> ifconfig and epoll_server, which is just some crap to get the user to >>>>>>> spin somewhere with a bit of a stack). >>>>>>> >>>>>>> barret >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Akaros" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Akaros" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>> >>> >> > -- > You received this message because you are subscribed to the Google Groups > "Akaros" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
