30 Nov, 2005

1 commit

  • set_page_dirty() will not cope with being handed a page * which is part of
    a compound page, but not the master page in that compound page. This case
    can occur via access_process_vm() if you attemp to write to another
    process's hugepage memory area using ptrace() (causing an oops or hang).

    This patch fixes the bug by only calling set_page_dirty() from
    access_process_vm() if the page is not a compound page. We already use a
    similar fix in bio_set_pages_dirty() for the case of direct io to
    hugepages.

    Signed-off-by: David Gibson
    Acked-by: William Irwin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Gibson
     

14 Nov, 2005

1 commit


10 Nov, 2005

1 commit

  • Before we did CLONE_THREAD, the way to check whether we were attaching
    to ourselves was to just check "current == task", but with CLONE_THREAD
    we should check that the thread group ID matches instead.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

07 Nov, 2005

1 commit

  • The sys_ptrace boilerplate code (everything outside the big switch
    statement for the arch-specific requests) is shared by most architectures.
    This patch moves it to kernel/ptrace.c and leaves the arch-specific code as
    arch_ptrace.

    Some architectures have a too different ptrace so we have to exclude them.
    They continue to keep their implementations. For sh64 I had to add a
    sh64_ptrace wrapper because it does some initialization on the first call.
    For um I removed an ifdefed SUBARCH_PTRACE_SPECIAL block, but
    SUBARCH_PTRACE_SPECIAL isn't defined anywhere in the tree.

    Signed-off-by: Christoph Hellwig
    Acked-by: Paul Mackerras
    Acked-by: Ralf Baechle
    Acked-By: David Howells
    Acked-by: Russell King
    Acked-by: Paul Mundt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     

31 Oct, 2005

1 commit

  • I could seldom reproduce a deadlock with a task not killable in T state
    (TASK_STOPPED, not TASK_TRACED) by attaching a NPTL threaded program to
    gdb, by segfaulting the task and triggering a core dump while some other
    task is executing exit_group and while one task is in ptrace_attached
    TASK_STOPPED state (not TASK_TRACED yet). This originated from a gdb
    bugreport (the fact gdb was segfaulting the task wasn't a kernel bug), but
    I just incidentally noticed the gdb bug triggered a real kernel bug as
    well.

    Most threads hangs in exit_mm because the core_dumping is still going, the
    core dumping hangs because the stopped task doesn't exit, the stopped task
    can't wakeup because it has SIGNAL_GROUP_EXIT set, hence the deadlock.

    To me it seems that the problem is that the force_sig_specific(SIGKILL) in
    zap_threads is a noop if the task has PF_PTRACED set (like in this case
    because gdb is attached). The __ptrace_unlink does nothing because the
    signal->flags is set to SIGNAL_GROUP_EXIT|SIGNAL_STOP_DEQUEUED (verified).

    The above info also shows that the stopped task hit a race and got the stop
    signal (presumably by the ptrace_attach, only the attach, state is still
    TASK_STOPPED and gdb hangs waiting the core before it can set it to
    TASK_TRACED) after one of the thread invoked the core dump (it's the core
    dump that sets signal->flags to SIGNAL_GROUP_EXIT).

    So beside the fact nobody would wakeup the task in __ptrace_unlink (the
    state is _not_ TASK_TRACED), there's a secondary problem in the signal
    handling code, where a task should ignore the ptrace-sigstops as long as
    SIGNAL_GROUP_EXIT is set (or the wakeup in __ptrace_unlink path wouldn't be
    enough).

    So I attempted to make this patch that seems to fix the problem. There
    were various ways to fix it, perhaps you prefer a different one, I just
    opted to the one that looked safer to me.

    I also removed the clearing of the stopped bits from the zap_other_threads
    (zap_other_threads was safe unlike zap_threads). I don't like useless
    code, this whole NPTL signal/ptrace thing is already unreadable enough and
    full of corner cases without confusing useless code into it to make it even
    less readable. And if this code is really needed, then you may want to
    explain why it's not being done in the other paths that sets
    SIGNAL_GROUP_EXIT at least.

    Even after this patch I still wonder who serializes the read of
    p->ptrace in zap_threads.

    Patch is called ptrace-core_dump-exit_group-deadlock-1.

    This was the trace I've got:

    test T ffff81003e8118c0 0 14305 1 14311 14309 (NOTLB)
    ffff810058ccdde8 0000000000000082 000001f4000037e1 ffff810000000013
    00000000000000f8 ffff81003e811b00 ffff81003e8118c0 ffff810011362100
    0000000000000012 ffff810017ca4180
    Call Trace:{try_to_wake_up+893} {finish_stop+87}
    {get_signal_to_deliver+1359} {do_signal+157}
    {ptrace_check_attach+222} {sys_ptrace+2293}
    {default_wake_function+0} {sys_ioctl+73}
    {sysret_signal+28} {ptregscall_common+103}

    test D ffff810011362100 0 14309 1 14305 14312 (NOTLB)
    ffff810053c81cf8 0000000000000082 0000000000000286 0000000000000001
    0000000000000195 ffff810011362340 ffff810011362100 ffff81002e338040
    ffff810001e0ca80 0000000000000001
    Call Trace:{try_to_wake_up+893} {wait_for_completion+173}
    {default_wake_function+0} {exit_mm+149}
    {do_exit+479} {do_group_exit+252}
    {get_signal_to_deliver+1451} {do_signal+157}
    {ptrace_check_attach+222} {specific_send_sig_info+2

    {force_sig_info+186} {do_int3+112}
    {retint_signal+61}
    test D ffff81002e338040 0 14311 1 14716 14305 (NOTLB)
    ffff81005ca8dcf8 0000000000000082 0000000000000286 0000000000000001
    0000000000000120 ffff81002e338280 ffff81002e338040 ffff8100481cb740
    ffff810001e0ca80 0000000000000001
    Call Trace:{try_to_wake_up+893} {wait_for_completion+173}
    {default_wake_function+0} {exit_mm+149}
    {do_exit+479} {__dequeue_signal+558}
    {do_group_exit+252} {get_signal_to_deliver+1451}
    {do_signal+157} {ptrace_check_attach+222}
    {specific_send_sig_info+208} {force_sig_info+186}
    {do_int3+112} {retint_signal+61}

    test D ffff810017ca4180 0 14312 1 14309 13882 (NOTLB)
    ffff81005d15fcb8 0000000000000082 ffff81005d15fc58 ffffffff80130816
    0000000000000897 ffff810017ca43c0 ffff810017ca4180 ffff81003e8118c0
    0000000000000082 ffffffff801317ed
    Call Trace:{activate_task+150} {try_to_wake_up+893}
    {wait_for_completion+173} {default_wake_function+0}
    {do_coredump+819} {thread_return+82}
    {get_signal_to_deliver+1444} {do_signal+157}
    {ptrace_check_attach+222} {specific_send_sig_info+2

    {_spin_unlock_irqrestore+5} {force_sig_info+186}
    {do_general_protection+159} {retint_signal+61}

    Signed-off-by: Andrea Arcangeli
    Cc: Roland McGrath
    Cc: Ingo Molnar
    Cc: Linus Torvalds
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrea Arcangeli
     

08 Sep, 2005

1 commit


01 May, 2005

2 commits


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds