Eric Lee / smarc-fsl-linux-kernel

27 Jun, 2006

2 commits

  • d5f70c00a   [PATCH] coredump: kill ptrace related stuff ... Browse Code »

    With this patch zap_process() sets SIGNAL_GROUP_EXIT while sending SIGKILL to
    the thread group. This means that a TASK_TRACED task

    1. Will be awakened by signal_wake_up(1)

    2. Can't sleep again via ptrace_notify()

    3. Can't go to do_signal_stop() after return
    from ptrace_stop() in get_signal_to_deliver()

    So we can remove all ptrace related stuff from coredump path.

    Signed-off-by: Oleg Nesterov
    Cc: "Eric W. Biederman"
    Cc: Roland McGrath
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     
  • df26c40e5   [PATCH] proc: Cleanup proc_fd_access_allowed ... Browse Code »

    In process of getting proc_fd_access_allowed to work it has developed a few
    warts. In particular the special case that always allows introspection and
    the special case to allow inspection of kernel threads.

    The special case for introspection is needed for /proc/self/mem.

    The special case for kernel threads really should be overridable
    by security modules.

    So consolidate these checks into ptrace.c:may_attach().

    The check to always allow introspection is trivial.

    The check to allow access to kernel threads, and zombies is a little
    trickier. mem_read and mem_write already verify an mm exists so it isn't
    needed twice. proc_fd_access_allowed only doesn't want a check to verify
    task->mm exits, s it prevents all access to kernel threads. So just move
    the task->mm check into ptrace_attach where it is needed for practical
    reasons.

    I did a quick audit and none of the security modules in the kernel seem to
    care if they are passed a task without an mm into security_ptrace. So the
    above move should be safe and it allows security modules to come up with
    more restrictive policy.

    Signed-off-by: Eric W. Biederman
    Cc: Stephen Smalley
    Cc: Chris Wright
    Cc: James Morris
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     

12 May, 2006

1 commit

  • f358166a9   ptrace_attach: fix possible deadlock schenario with irqs ... Browse Code »

    Eric Biederman points out that we can't take the task_lock while holding
    tasklist_lock for writing, because another CPU that holds the task lock
    might take an interrupt that then tries to take tasklist_lock for writing.

    Which would be a nasty deadlock, with one CPU spinning forever in an
    interrupt handler (although admittedly you need to really work at
    triggering it ;)

    Since the ptrace_attach() code is special and very unusual, just make it
    be extra careful, and use trylock+repeat to avoid the possible deadlock.

    Cc: Oleg Nesterov
    Cc: Eric W. Biederman
    Cc: Roland McGrath
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

08 May, 2006

1 commit

  • f5b40e363   Fix ptrace_attach()/ptrace_traceme()/de_thread() race ... Browse Code »

    This holds the task lock (and, for ptrace_attach, the tasklist_lock)
    over the actual attach event, which closes a race between attacking to a
    thread that is either doing a PTRACE_TRACEME or getting de-threaded.

    Thanks to Oleg Nesterov for reminding me about this, and Chris Wright
    for noticing a lost return value in my first version.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

14 Apr, 2006

1 commit

  • e57a50598   [PATCH] fix non-leader exec under ptrace ... Browse Code »

    This reverts most of commit 30e0fca6c1d7d26f3f2daa4dd2b12c51dadc778a.
    It broke the case of non-leader MT exec when ptraced.
    I think the bug it was intended to fix was already addressed by commit
    788e05a67c343fa22f2ae1d3ca264e7f15c25eaf.

    Signed-off-by: Roland McGrath
    Acked-by: Oleg Nesterov
    Signed-off-by: Linus Torvalds

    Roland McGrath
     

02 Apr, 2006

1 commit

29 Mar, 2006

1 commit

16 Feb, 2006

1 commit

  • 5ecfbae09   [PATCH] fix zap_thread's ptrace related problems ... Browse Code »

    1. The tracee can go from ptrace_stop() to do_signal_stop()
    after __ptrace_unlink(p).

    2. It is unsafe to __ptrace_unlink(p) while p->parent may wait
    for tasklist_lock in ptrace_detach().

    Signed-off-by: Oleg Nesterov
    Cc: Roland McGrath
    Cc: Ingo Molnar
    Cc: Christoph Hellwig
    Cc: Eric W. Biederman
    Signed-off-by: Linus Torvalds

    Oleg Nesterov
     

15 Feb, 2006

1 commit

  • 16bf13484   [PATCH] compound page: no access_process_vm check ... Browse Code »

    The PageCompound check before access_process_vm's set_page_dirty_lock is no
    longer necessary, so remove it. But leave the PageCompound checks in
    bio_set_pages_dirty, dio_bio_complete and nfs_free_user_pages: at least some
    of those were introduced as a little optimization on hugetlb pages.

    Signed-off-by: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     

12 Jan, 2006

1 commit

  • c59ede7b7   [PATCH] move capable() to capability.h ... Browse Code »

    - Move capable() from sched.h to capability.h;

    - Use where capable() is used
    (in include/, block/, ipc/, kernel/, a few drivers/,
    mm/, security/, & sound/;
    many more drivers/ to go)

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy.Dunlap
     

09 Jan, 2006

1 commit

  • 6b9c7ed84   [PATCH] use ptrace_get_task_struct in various places ... Browse Code »

    The ptrace_get_task_struct() helper that I added as part of the ptrace
    consolidation is useful in variety of places that currently opencode it.
    Switch them to the common helpers.

    Add a ptrace_traceme() helper that needs to be explicitly called, and simplify
    the ptrace_get_task_struct() interface. We don't need the request argument
    now, and we return the task_struct directly, using ERR_PTR() for error
    returns. It's a bit more code in the callers, but we have two sane routines
    that do one thing well now.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     

30 Nov, 2005

1 commit

  • 5bd0190bf   [PATCH] Fix crash when ptrace poking hugepage areas ... Browse Code »

    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

  • 28d838cc4   Fix ptrace self-attach rule ... Browse Code »

    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

  • 481bed454   [PATCH] consolidate sys_ptrace() ... Browse Code »

    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

  • 30e0fca6c   [PATCH] ptrace/coredump/exit_group deadlock ... Browse Code »

    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

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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