Re: [BUG??] Deadlock between kswapd andsys_inotify_add_watch(lockdep report)

[Peter Zijlstra]

On Mon, 2009-02-02 at 20:56 +0900, MinChan Kim wrote:
> Thanks for kind explanation. :)
> Unfortunately, I still have a question. :(

No problem :-)

> > > I think if reclaim context which have GFP_FS already have lock A and then 
> > > do pageout, if writepage need the lock A, we have to catch such a case. 
> > > I thought Nick's patch's goal catchs such a case. 
> > 
> > Correct, it exactly does that.
> 
> But, I think such a case can be caught by lockdep of recursive detection 
> which is existed long time ago by making you.

(Ingo wrote that code)

> what's difference Nick's patch and recursive lockdep ?

Very good question indeed. Every time I started to write an answer I
realize its wrong.

The below is half the answer:

/*
 * Check whether we are holding such a class already.
 *
 * (Note that this has to be done separately, because the graph cannot
 * detect such classes of deadlocks.)
 *
 * Returns: 0 on deadlock detected, 1 on OK, 2 on recursive read
 */
static int
check_deadlock(struct task_struct *curr, struct held_lock *next,
               struct lockdep_map *next_instance, int read)

So in order for the reclaim report to trigger we have to actually hit
that code path that has the recursion in it. The reclaim context
annotation by Nick ensures we detect such cases without having to do
that.

The second half, to which I cannot seem to get a decent answer to atm,
is why the recursion case isn't detected by the graph.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/