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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1301419214.14261.289.camel@gandalf.stny.rr.com>
Date:	Tue, 29 Mar 2011 13:20:14 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC][PATCH] lockdep: Print a nice description of an irq
 locking issue

On Tue, 2011-03-29 at 13:14 -0400, Steven Rostedt wrote:
>    
>      ---
>     other info that might help us debug this:
>     
>     Chain exists of:
>       &rq->lock --> lockA --> lockC
>     
>      Possible interrupt unsafe locking scenario:
>     
>            CPU0                    CPU1
>            ----                    ----
>       lock(lockC);
>                                    local_irq_disable();
>                                    lock(&rq->lock);
>                                    lock(lockA);
>       <Interrupt>
>         lock(&rq->lock)
>     
>      *** DEADLOCK ***
>     

Note, the above output is real. To produce this output, I wrote a module
that created a "lockA", "lockB" and "lockC" and had the following:

        spin_lock_irq(&lockA);
        spin_lock(&lockB);
        spin_unlock(&lockB);
        spin_unlock_irq(&lockA);

        spin_lock_irq(&lockB);
        spin_lock(&lockC);
        spin_unlock(&lockC);
        spin_unlock_irq(&lockB);

        spin_lock(&lockC);
        spin_unlock(&lockC);
        ret = register_trace_sched_switch(probe_switch, NULL);

static void
probe_switch(void *ignore, struct task_struct *p, struct task_struct *n)
{
        unsigned long flags;

        spin_lock_irqsave(&lockA, flags);
        spin_unlock_irqrestore(&lockA, flags);
}


probe_switch is called via the trace_sched_switch() trace point that is
called with the rq lock held, producing the call chain that will trigger
lockdep to produce a dump.

-- Steve




--
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