lkml.org 
[lkml]   [1999]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectFD array expansion problem
    I've seen a problem with fd array expansion in the recent kernels (namely, in
    2.3.18).

    dup2 with a very large newfd argument causes an Oops in fd_install.

    Unable to handle kernel paging request at virtual address c8052000
    c012fae2
    *pde = 07e0f063
    Oops: 0002
    CPU: 0
    EIP: 0010:[<c012fae2>]
    Using defaults from ksymoops -t elf32-i386 -a i386
    EFLAGS: 00010286
    eax: c8052000 ebx: 00000001 ecx: c384d8c0 edx: c61a8b60
    esi: c384d8c0 edi: c61a8b60 ebp: 00004000 esp: c753ffb8
    ds: 0018 es: 0018 ss: 0018
    Process tt (pid: 23790, stackpage=c753f000)
    Stack: 08048594 bffff8a8 c0107e80 00000000 00004000 00004000 00002000
    08048594
    bffff8a8 ffffffda 0000002b 0000002b 0000003f 400d4d71 00000023
    00000206
    bffff88c 0000002b
    Call Trace: [<c0107e80>]
    Code: 87 10 85 d2 74 16 8d 42 10 ff 4a 10 0f 94 c0 84 c0 74 09 52

    >>EIP; c012fae2 <sys_dup2+d6/fc> <=====
    Trace; c0107e80 <tracesys+18/23>
    Code; c012fae2 <sys_dup2+d6/fc>
    00000000 <_EIP>:
    ode; c012fae2 <sys_dup2+d6/fc> <=====
    0: 87 10 xchgl %edx,(%eax) <=====
    Code; c012fae4 <sys_dup2+d8/fc>
    2: 85 d2 testl %edx,%edx
    Code; c012fae6 <sys_dup2+da/fc>
    4: 74 16 je 1c <_EIP+0x1c> c012fafe <sys_dup2+f2/fc>
    Code; c012fae8 <sys_dup2+dc/fc>
    6: 8d 42 10 leal 0x10(%edx),%eax
    Code; c012faeb <sys_dup2+df/fc>
    9: ff 4a 10 decl 0x10(%edx)
    Code; c012faee <sys_dup2+e2/fc>
    c: 0f 94 c0 sete %al
    Code; c012faf1 <sys_dup2+e5/fc>
    f: 84 c0 testb %al,%al
    Code; c012faf3 <sys_dup2+e7/fc>
    11: 74 09 je 1c <_EIP+0x1c> c012fafe <sys_dup2+f2/fc>
    Code; c012faf5 <sys_dup2+e9/fc>
    13: 52 pushl %edx


    BTW, does anyone know why fd array manipulations are performed via atomic
    operation (xchg) in some places (fd_install, expand_fdset)?
    It looks strange because
    1) atomic operations don't cover all accesses;
    2) these code parts are already protected by a write lock.

    Best regards
    Andrey V.
    Savochkin

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:54    [W:0.019 / U:30.808 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site