Messages in this thread | | | Date | Mon, 2 Feb 2009 22:43:48 +0900 | Subject | Re: [BUG??] Deadlock between kswapd and sys_inotify_add_watch(lockdep report) | From | MinChan Kim <> |
| |
On Mon, Feb 2, 2009 at 10:09 PM, Peter Zijlstra <peterz@infradead.org> wrote: > 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.
In my case and Nick's patch's example hit code path that has the recursion in it. then reported it.
Do I miss something ?
> 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. > > > >
-- Kinds regards, MinChan Kim
| |