lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAKWKT+b_bjQ8mB1OsBpbUym0VK52pYT-SH8p+A+=e1vS-SBcRw@mail.gmail.com>
Date:	Mon, 10 Dec 2012 21:01:07 +0800
From:	Qiang Gao <gaoqiangscut@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: kernel panic when doing do_exit

OS version: centos 6.2   kernel: 2.6.32-220.7.1

call trace from the vmcore:

crash> bt
PID: 31437  TASK: ffff880832e260c0  CPU: 13  COMMAND: "tt"
 #0 [ffff88082b751b30] die at ffffffff8100ef7f
 #1 [ffff88082b751b60] do_general_protection at ffffffff814a5492
 #2 [ffff88082b751b90] general_protection at ffffffff814a4f05
    [exception RIP: update_cfs_shares+50]
    RIP: ffffffff81052202  RSP: ffff88082b751c48  RFLAGS: 00010086
    RAX: dead000000000000  RBX: ffff88082ee7d880  RCX: ffff880434af4cc0
    RDX: 000000000000000d  RSI: 0000000091771fba  RDI: ffff88082ee7d880
    RBP: ffff88082b751c68   R8: ffff880434af4cc0   R9: 0000000000989680
    R10: 0000000000000400  R11: 0000000000000000  R12: ffff880832e26100
    R13: 0000000000000001  R14: 0000000000000001  R15: ffff88044e4b4840
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0000
 #3 [ffff88082b751c70] dequeue_task_fair at ffffffff8105243f
 #4 [ffff88082b751cb0] dequeue_task at ffffffff8104dc73
 #5 [ffff88082b751ce0] deactivate_task at ffffffff8104dcc4
 #6 [ffff88082b751cf0] thread_return at ffffffff814a22ef
 #7 [ffff88082b751e30] do_exit at ffffffff810625ea
 #8 [ffff88082b751f40] do_group_exit at ffffffff81062951
 #9 [ffff88082b751f70] sys_exit_group at ffffffff810629d7
#10 [ffff88082b751f80] system_call_fastpath at ffffffff8100afb2
    RIP: 00000038e849a3cf  RSP: 00007fff8febc268  RFLAGS: 00010246
    RAX: 00000000000000e7  RBX: ffffffff8100afb2  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: 000000000000003c  RDI: 0000000000000000
    RBP: 0000000000000000   R8: 00000000000000e7   R9: ffffffffffffffb0
    R10: 0000000000000000  R11: 0000000000000246  R12: ffffffff810629d7
    R13: ffff88082b751f78  R14: 0000000000000000  R15: 00007fff8febc360
    ORIG_RAX: 00000000000000e7  CS: 0033  SS: 002b


static void update_cfs_shares(struct cfs_rq *cfs_rq)
{
    struct task_group *tg;
    struct sched_entity *se;
    long load_weight, load, shares;

    tg = cfs_rq->tg;
    se = tg->se[cpu_of(rq_of(cfs_rq))];  <------dies  here
...........
}

    tg->se=0xdead000000000000  because I set it when it was freed.


command "tt" does nothing bug loop for many times and then exit  and I put "tt"
in a cpu-cgroup.

it seems that  if a context switch happens between  cgroup_exit and
the last schedule() ,
 the cgroup-releated structures will be freed and later dereference
will result in a kernel panic

I'm not quite familar with this code and anyone has any idea ?


    exit_thread();
    cgroup_exit(tsk, 1);    <-------------here

    if (group_dead && tsk->signal->leader)
        disassociate_ctty(1);

    module_put(task_thread_info(tsk)->exec_domain->module);

    proc_exit_connector(tsk);

    /*
     * Flush inherited counters to the parent - before the parent
     * gets woken up by child-exit notifications.
     */
    perf_event_exit_task(tsk);

    exit_notify(tsk, group_dead);
#ifdef CONFIG_NUMA
    task_lock(tsk);
    mpol_put(tsk->mempolicy);
    tsk->mempolicy = NULL;
    task_unlock(tsk);
#endif
#ifdef CONFIG_FUTEX
    if (unlikely(current->pi_state_cache))
        kfree(current->pi_state_cache);
#endif
    /*
     * Make sure we are holding no locks:
     */
    debug_check_no_locks_held(tsk);
    /*
     * We can do this unlocked here. The futex code uses this flag
     * just to verify whether the pi state cleanup has been done
     * or not. In the worst case it loops once more.
     */
    tsk->flags |= PF_EXITPIDONE;

    if (tsk->io_context)
        exit_io_context();

    if (tsk->splice_pipe)
        __free_pipe_info(tsk->splice_pipe);

    validate_creds_for_do_exit(tsk);
   /* actually,I insert some code here to make it easy to
reproduce.
{
    volatile int i=0;
    volatile int j=0;
    volatile int k=0;
    for(j=0;j<3;j++)
    {
        i=0;
        while(i++<100000000)
        {
            k++;
        }
        //schedule();
    }
    return k;
}
*/
    preempt_disable();
    exit_rcu();
    /* causes final put_task_struct in finish_task_switch(). */
    tsk->state = TASK_DEAD;
    schedule();   <------------------------------------here
    BUG();
    /* Avoid "noreturn function does return".  */
    for (;;)
        cpu_relax();    /* For when BUG is null */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ