linux-kernel - Re: [PATCH] watchdog: print all locks on a softlock

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]

Date:	Thu, 1 May 2014 22:09:01 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Don Zickus <dzickus@...hat.com>
Cc:	Eric Paris <eparis@...hat.com>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michal Hocko <mhocko@...e.cz>, Ben Zhang <benzh@...omium.org>
Subject: Re: [PATCH] watchdog: print all locks on a softlock

On Thu, May 01, 2014 at 03:17:20PM -0400, Don Zickus wrote:
> On Thu, May 01, 2014 at 02:55:35PM -0400, Eric Paris wrote:
> > If the CPU hits a softlockup this patch will also have it print the
> > information about all locks being held on the system.  This might help
> > determine if a lock is being held too long leading to this problem.
> 
> I am not sure this helps you.  A softlockup is the result of pre-emption
> disabled, ie the scheduler not being called after 60 seconds.  Holding a
> lock does not disable pre-emption usually.  So I don't think this is going
> to add anything.
> 
> Are you trying to debug a hung task?  The the hung_task thread checks to
> see if a task hasn't scheduled in 2 minutes or so.  That could be the
> result of long lock (but that output already dumps the lockdep stuff).

There may be some deadlocks that lockdep doesn't detect yet. 2 example:

1) spinlock <-> IPI dependency


        CPU 0                                            CPU 1
        --------------------------------------------------------
        spin_lock_irq(A)
        smp_send_function_single_async(CPU 1, func)
                                                         //IPI
                                                         func {
                                                            spin_lock(1)
                                                         }

But this should be resolved with a virtual lock on the IPI functions.
I should try that.

2) rwlock <-> IPI

        CPU 0                                            CPU 1
        --------------------------------------------------------
        read_lock(A)
                                                         write_lock_irq(A)
        smp_send_function_single(CPU 1, func)
                                                         //IPI never happens

This one is much trickier.

Anyway those are the only scenario I know of but there may be more. When possible
we want to extend lockdep to detect new scenarios of deadlock but we don't have the
guarantee that it can detect everything.

So, could be useful...
--
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/