On Mon, Nov 16, 2020 at 03:37:29PM +, Matthew Wilcox wrote:
> > > Something I believe lockdep is missing is a way to annotate "This lock
> > > will be released by a softirq". If we had lockdep for lock_page(), this
> > > would be a great case to show off. The filesystem locks the page, then
On Mon, Nov 16, 2020 at 06:05:47PM +0900, Byungchul Park wrote:
> On Thu, Nov 12, 2020 at 11:58:44PM +0900, Byungchul Park wrote:
> > > > FYI, roughly Lockdep is doing:
> > > >
> > > >1. Dependency check
> > > >2. Lock usage correctness check (including RCU)
> > > >3. IRQ related usage
On Wed, Nov 18, 2020 at 09:45:40AM +0800, Boqun Feng wrote:
> Hi Matthew,
>
> On Mon, Nov 16, 2020 at 03:37:29PM +, Matthew Wilcox wrote:
> [...]
> >
> > It's not just about lockdep for semaphores. Mutexes will spin if the
> > current owner is still running, so to convert an
Hi Matthew,
On Mon, Nov 16, 2020 at 03:37:29PM +, Matthew Wilcox wrote:
[...]
>
> It's not just about lockdep for semaphores. Mutexes will spin if the
> current owner is still running, so to convert an interrupt-released
> semaphore to a mutex, we need a way to mark the mutex as being
On Mon, Nov 16, 2020 at 05:57:57PM +0900, Byungchul Park wrote:
> On Thu, Nov 12, 2020 at 02:52:51PM +, Matthew Wilcox wrote:
> > On Thu, Nov 12, 2020 at 09:26:12AM -0500, Steven Rostedt wrote:
> > > > FYI, roughly Lockdep is doing:
> > > >
> > > >1. Dependency check
> > > >2. Lock
On Thu, Nov 12, 2020 at 11:58:44PM +0900, Byungchul Park wrote:
> > > FYI, roughly Lockdep is doing:
> > >
> > >1. Dependency check
> > >2. Lock usage correctness check (including RCU)
> > >3. IRQ related usage correctness check with IRQFLAGS
> > >
> > > 2 and 3 should be there forever
On Thu, Nov 12, 2020 at 02:52:51PM +, Matthew Wilcox wrote:
> On Thu, Nov 12, 2020 at 09:26:12AM -0500, Steven Rostedt wrote:
> > > FYI, roughly Lockdep is doing:
> > >
> > >1. Dependency check
> > >2. Lock usage correctness check (including RCU)
> > >3. IRQ related usage
On Thu, Nov 12, 2020 at 02:56:49PM +0100, Daniel Vetter wrote:
> > > I think I understand it. For things like completions and other "wait for
> > > events" we have lockdep annotation, but it is rather awkward to implement.
> > > Having something that says "lockdep_wait_event()" and
> > >
On Thu, Nov 12, 2020 at 11:28 PM Steven Rostedt wrote:
>
> On Thu, 12 Nov 2020 17:10:30 +0900
> Byungchul Park wrote:
>
> > 2. Does Lockdep do what a deadlock detection tool should do? From
> >internal engine to APIs, all the internal data structure and
> >algotithm of Lockdep is only
On Thu, Nov 12, 2020 at 09:26:12AM -0500, Steven Rostedt wrote:
> > FYI, roughly Lockdep is doing:
> >
> >1. Dependency check
> >2. Lock usage correctness check (including RCU)
> >3. IRQ related usage correctness check with IRQFLAGS
> >
> > 2 and 3 should be there forever which is
On Thu, 12 Nov 2020 17:10:30 +0900
Byungchul Park wrote:
> 2. Does Lockdep do what a deadlock detection tool should do? From
>internal engine to APIs, all the internal data structure and
>algotithm of Lockdep is only looking at lock(?) acquisition order.
>Fundamentally Lockdep cannot
On Thu, Nov 12, 2020 at 11:33 AM Byungchul Park wrote:
>
> On Wed, Nov 11, 2020 at 09:36:09AM -0500, Steven Rostedt wrote:
> > And this is especially true with lockdep, because lockdep only detects the
> > deadlock, it doesn't tell you which lock was the incorrect locking.
> >
> > For example. If
On Wed, Nov 11, 2020 at 09:36:09AM -0500, Steven Rostedt wrote:
> And this is especially true with lockdep, because lockdep only detects the
> deadlock, it doesn't tell you which lock was the incorrect locking.
>
> For example. If we have a locking chain of:
>
> A -> B -> D
>
> A -> C -> D
>
On Thu, Nov 12, 2020 at 05:51:14PM +0900, Byungchul Park wrote:
> On Thu, Nov 12, 2020 at 03:15:32PM +0900, Byungchul Park wrote:
> > > If on the other hand there's some bug in lockdep itself that causes
> > > excessive false positives, it's better to limit the number of reports
> > > to one per
On Thu, Nov 12, 2020 at 03:15:32PM +0900, Byungchul Park wrote:
> > If on the other hand there's some bug in lockdep itself that causes
> > excessive false positives, it's better to limit the number of reports
> > to one per bootup, so that it's not seen as a nuisance debugging
> > facility.
>
On Thu, Nov 12, 2020 at 12:16:50AM +0100, Thomas Gleixner wrote:
> Wrappers which make things simpler are always useful, but the lack of
> wrappers does not justify a wholesale replacement.
Totally right. Lack of wrappers doesn't matter at all. That could be
achieved easily by modifying the
On Wed, Nov 11, 2020 at 11:54:41AM +0100, Ingo Molnar wrote:
> > We cannot get reported other than the first one.
>
> Correct. Experience has shown that the overwhelming majority of
> lockdep reports are single-cause and single-report.
>
> This is an optimal approach, because after a decade of
On Wed, Nov 11 2020 at 09:36, Steven Rostedt wrote:
> Ingo Molnar wrote:
>> Not sure I understand the "problem 2)" outlined here, but I'm looking
>> forward to your patchset!
>>
> I think I understand it. For things like completions and other "wait for
> events" we have lockdep annotation, but
On Wed, 11 Nov 2020 11:54:41 +0100
Ingo Molnar wrote:
> * Byungchul Park wrote:
>
> > PROBLEM 1) First of all, Lockdep gets disabled on the first detection.
>
> Lockdep disabling itself after the first warning was an intentional
> and deliberate design decision. (See more details below.)
>
* Byungchul Park wrote:
> PROBLEM 1) First of all, Lockdep gets disabled on the first detection.
Lockdep disabling itself after the first warning was an intentional
and deliberate design decision. (See more details below.)
>What if there are more than two problems?
So the usual way
Hello folks,
We have no choise but to use Lockdep to track dependencies for deadlock
detection with the current kernel. I'm wondering if they are satifsied
in that tool. Lockdep has too big problems to continue to use.
---
PROBLEM 1) First of all, Lockdep gets disabled on the first detection.
21 matches
Mail list logo
