lkml.org 
[lkml]   [2011]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: processes stuck in llseek
    Date
    Excerpts from Dan Merillat's message of 2011-08-15 23:59:50 -0400:
    > I noticed a series of hung_task notifications in dmesg, so I went
    > poking at it. Process is 'dropbox', and it's stuck trying to llseek
    > it's library.zip file.
    >
    > strace of dropbox:
    > ...
    > stat("/home/x/.dropbox-dist/library.zip", {st_mode=S_IFREG|0755,
    > st_size=11575179, ...}) = 0
    > open("/home/x/.dropbox-dist/library.zip", O_RDONLY) = 3
    > fstat(3, {st_mode=S_IFREG|0755, st_size=11575179, ...}) = 0
    > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
    > 0) = 0x7fa766ea8000
    > fstat(3, {st_mode=S_IFREG|0755, st_size=11575179, ...}) = 0
    > lseek(3, 11571200, SEEK_SET
    >
    > SEEK_SET is less than st_size
    >
    > strace of dd if=library.zip of=/dev/null bs=1 seek=11571200:
    >
    > open("library.zip", O_RDONLY) = 3
    > dup2(3, 0) = 0
    > close(3) = 0
    > lseek(0, 0, SEEK_CUR
    >
    > [72960.716080] INFO: task dropbox:1348 blocked for more than 120 seconds.
    > [72960.716084] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
    > disables this message.
    > [72960.716087] dropbox D ffff8800762d8a78 0 1348 1 0x00000004
    > [72960.716092] ffff880069cede18 0000000000000086 0000000000096000
    > 0000000000000000
    > [72960.716097] ffff880069cec000 00000000000119c0 ffff8800762d8700
    > 00000000000119c0
    > [72960.716101] ffff880069cedfd8 0000000000004000 ffff880069cedfd8
    > 00000000000119c0
    > [72960.716106] Call Trace:
    > [72960.716113] [<ffffffff81331f9e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
    > [72960.716119] [<ffffffff8155710a>] ? retint_restore_args+0xe/0xe
    > [72960.716124] [<ffffffff810e8ef1>] ? noop_llseek+0xa/0xa
    > [72960.716129] [<ffffffff810340ff>] ? mutex_spin_on_owner+0x1c/0x45
    > [72960.716133] [<ffffffff81555be0>] __mutex_lock_slowpath+0xd2/0x116
    > [72960.716137] [<ffffffff81559edd>] ? do_page_fault+0x374/0x3e6
    > [72960.716140] [<ffffffff81555a87>] mutex_lock+0x16/0x27
    > [72960.716146] [<ffffffff812c8ad7>] btrfs_file_llseek+0x38/0x297
    > [72960.716150] [<ffffffff81331fda>] ? trace_hardirqs_off_thunk+0x3a/0x6c
    > [72960.716153] [<ffffffff810e8f2c>] vfs_llseek+0x2e/0x30
    > [72960.716155] [<ffffffff810e9311>] sys_lseek+0x3e/0x5d
    > [72960.716159] [<ffffffff8155d4fb>] system_call_fastpath+0x16/0x1b
    >
    > Oddly enough, it's just llseek. I can copy/read the file sequentially
    > just fine, but llseek fails on a copy as well. Once I get physically
    > to the system I'll recompile to an unmodified kernel and try again.
    > Other files of the same approximate age llseek correctly.
    >
    > Kernel is 3.1-rc1 with the fglrx module from AMD and the following
    > patch: (I was playing with cross-subvolume reflinking, but not on
    > this file)

    Dan Carpenter sent a patch for this, I'll get it queued up for rc3.

    -chris


    \
     
     \ /
      Last update: 2011-08-16 14:53    [W:0.024 / U:2.428 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site