Ouch, nasty 😑
Somehow GCC split the loop in 1+N, but look at the +N part (from +0x30 to
+0x4f).
Unless I am blind, %ecx never gets reloaded with 16 😱
So, it being zero, we keep copying nothing.


ffffffffc2088d00 <backtrace_user_list>:
ffffffffc2088d00:       55                      push   %rbp
ffffffffc2088d01:       49 89 f9                mov    %rdi,%r9
ffffffffc2088d04:       49 89 ca                mov    %rcx,%r10
ffffffffc2088d07:       31 c0                   xor    %eax,%eax
ffffffffc2088d09:       b9 10 00 00 00          mov    $0x10,%ecx
ffffffffc2088d0e:       48 89 e5                mov    %rsp,%rbp
ffffffffc2088d11:       48 83 ec 10             sub    $0x10,%rsp
ffffffffc2088d15:       48 8d 7d f0             lea    -0x10(%rbp),%rdi
ffffffffc2088d19:       fc                      cld
ffffffffc2088d1a:       f3 a4                   rep movsb
%ds:(%rsi),%es:(%rdi)
ffffffffc2088d1c:       85 c0                   test   %eax,%eax
ffffffffc2088d1e:       b8 00 00 00 00          mov    $0x0,%eax
ffffffffc2088d23:       75 2c                   jne    ffffffffc2088d51
<backtrace_user_list+0x51>
ffffffffc2088d25:       4d 85 d2                test   %r10,%r10
ffffffffc2088d28:       74 27                   je     ffffffffc2088d51
<backtrace_user_list+0x51>
ffffffffc2088d2a:       45 31 db                xor    %r11d,%r11d
ffffffffc2088d2d:       eb 06                   jmp    ffffffffc2088d35
<backtrace_user_list+0x35>
ffffffffc2088d2f:       90                      nop
ffffffffc2088d30:       49 39 c2                cmp    %rax,%r10
ffffffffc2088d33:       76 1c                   jbe    ffffffffc2088d51
<backtrace_user_list+0x51>
ffffffffc2088d35:       48 83 c0 01             add    $0x1,%rax
ffffffffc2088d39:       45 89 d8                mov    %r11d,%r8d
ffffffffc2088d3c:       48 8b 75 f0             mov    -0x10(%rbp),%rsi
ffffffffc2088d40:       4c 89 4c c2 f8          mov    %r9,-0x8(%rdx,%rax,8)
ffffffffc2088d45:       4c 8b 4d f8             mov    -0x8(%rbp),%r9
ffffffffc2088d49:       fc                      cld
ffffffffc2088d4a:       f3 a4                   rep movsb
%ds:(%rsi),%es:(%rdi)
ffffffffc2088d4c:       45 85 c0                test   %r8d,%r8d
ffffffffc2088d4f:       74 df                   je     ffffffffc2088d30
<backtrace_user_list+0x30>
ffffffffc2088d51:       c9                      leaveq
ffffffffc2088d52:       c3                      retq


ffffffffc209607f:       b8 f2 ff ff ff          mov    $0xfffffff2,%eax
ffffffffc2096084:       e9 93 2c ff ff          jmpq   ffffffffc2088d1c
<backtrace_user_list+0x1c>
ffffffffc2096089:       41 b8 f2 ff ff ff       mov    $0xfffffff2,%r8d
ffffffffc209608f:       e9 b8 2c ff ff          jmpq   ffffffffc2088d4c
<backtrace_user_list+0x4c>



On Wed, Dec 9, 2015 at 6:12 PM, Barret Rhoden <[email protected]> wrote:

> On 2015-12-09 at 18:06 "'Davide Libenzi' via Akaros"
> <[email protected]> wrote:
> > So, what is a case that trips?
> > Can you give me a way to reproduce? From your email is not clear.
>
> If you:
>
> - checkout origin/nasty-bug
> - make userclean
> - make tests
> - make fill-kfs
> - make
> - run akaros
>
> / $ ash ifconfig
> / $ ash epoll_server
>
> should hang, CTRL-G should work (can ps, etc)
>
> CTRL-B
>
> should hang and when you look at the registers in qemu, you should see
> the same ones i had in my original email.
>
> note that the check here:
>
>         if (frame[0] == fp) {
> //          printk("fp %p, frame[0] %p, frame %p, *fp %p\n", fp, frame[0],
> //                 frame, *(uintptr_t*)fp);
>             while (1) ;
>
>         }
>
> will also trip on a successful BT, since copy_from_user PF'd and the
> copy didn't happen.  if that happens, you should see:
>
> Core 0 is in __handler_kernel_page_fault() at kern/arch/x86/trap.c:289
>
> (among other things).
>
> I gotta run for now - will bang my face into my keyboard some more
> tomorrow.  =)
>
> Barret
>
>
>
> >
> >
> > On Wed, Dec 9, 2015 at 6:02 PM, Barret Rhoden <[email protected]>
> > wrote:
> >
> > > On 2015-12-10 at 00:53 ron minnich <[email protected]> wrote:
> > > > yeah I talked to barrett about this one and it seems D is not set.
> > > > Would have been nice!
> > >
> > > yep, tried that one.  =(
> > >
> > > i figure it's something crazy like that though.
> > >
> > > i tried taking the code out of its current location and do something
> > > similar, but couldn't trigger it:
> > >
> > > e.g.
> > >
> > > void xme(void)
> > > {
> > >     void *uaddr;
> > >     uintptr_t frame[2];
> > >     uintptr_t test[2];
> > >     int err;
> > >
> > >     assert(current);
> > >     uaddr = mmap(current, 0, PGSIZE, PROT_READ | PROT_WRITE,
> > > MAP_ANON, -1, 0);
> > >     assert(uaddr);
> > >
> > >     frame[0] = 0x0102030405060708;
> > >     frame[1] = 0xa0b0c0d0e0f01122;
> > >
> > >     memcpy(uaddr, frame, 2 * sizeof(uintptr_t));
> > >     memcpy(test, uaddr, 2 * sizeof(uintptr_t));
> > >
> > >     assert(memcmp(frame, test, 2 * sizeof(uintptr_t)) == 0);
> > >
> > >     memset(test, 0, 2 * sizeof(uintptr_t));
> > >
> > >     asm volatile("nop;nop;nop;");
> > >     err = copy_from_user(test, uaddr, 2 * sizeof(uintptr_t));
> > >     asm volatile("nop;nop;nop;");
> > >
> > >     assert(!err);
> > >     assert(memcmp(frame, test, 2 * sizeof(uintptr_t)) == 0);
> > >
> > > }
> > >
> > > and kfunc xme, or also run it from CTRL-Q (k/a/x/init.c).  but those
> > > didn't trip.
> > >
> > > then i figured i'd try forgetting the uaddr, and just clobber some
> > > user memory with the same uaddr as in the failing case
> > > (0x00007f7fffbfef50).  that didn't make a difference either.  the
> > > alignment on both src and dst is 0x10, so that seems fine too.
> > >
> > >
> > >
> > > --
> > > 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.

Reply via email to