From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with SMTP id F19E95F0001 for ; Mon, 2 Feb 2009 09:16:31 -0500 (EST) Received: by yw-out-1718.google.com with SMTP id 5so473334ywm.26 for ; Mon, 02 Feb 2009 06:16:30 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1233582937.4787.217.camel@laptop> References: <20090202101735.GA12757@barrios-desktop> <28c262360902020225w6419089ft2dda30da9dfb32a9@mail.gmail.com> <1233571202.4787.124.camel@laptop> <20090202112721.GA13532@barrios-desktop> <1233575085.4787.140.camel@laptop> <20090202115627.GB13532@barrios-desktop> <1233580147.4787.207.camel@laptop> <28c262360902020543we62e394kb21c16f599824552@mail.gmail.com> <1233582937.4787.217.camel@laptop> Date: Mon, 2 Feb 2009 23:16:30 +0900 Message-ID: <28c262360902020616t57fab9cas96fdf9aa4977072b@mail.gmail.com> Subject: Re: [BUG??] Deadlock between kswapd and sys_inotify_add_watch(lockdep report) From: MinChan Kim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: Peter Zijlstra Cc: Nick Piggin , linux kernel , linux mm , Ingo Molnar List-ID: On Mon, Feb 2, 2009 at 10:55 PM, Peter Zijlstra wrote: > On Mon, 2009-02-02 at 22:43 +0900, MinChan Kim wrote: >> On Mon, Feb 2, 2009 at 10:09 PM, Peter Zijlstra 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 ? > > I'm not sure I fully understand your question, but let me try and > explain more clearly. > It's very clear. Today, I understood lockdep concept deeper as your patient advise. Thanks, Peter. :) -- Kinds regards, MinChan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org