From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by kanga.kvack.org (Postfix) with SMTP id BAE876B003D for ; Sat, 2 May 2009 11:12:07 -0400 (EDT) Subject: Re: [PATCH] use GFP_NOFS in kernel_event() From: Eric Paris In-Reply-To: <20090502080405.GA6432@localhost> References: <20090430020004.GA1898@localhost> <20090429191044.b6fceae2.akpm@linux-foundation.org> <1241097573.6020.7.camel@localhost.localdomain> <20090430134821.GB8644@localhost> <20090430142807.GA13931@localhost> <1241103132.6020.17.camel@localhost.localdomain> <20090502022515.GB29422@localhost> <20090502080405.GA6432@localhost> Content-Type: text/plain Date: Sat, 02 May 2009 11:11:12 -0400 Message-Id: <1241277072.3086.47.camel@dhcp231-142.rdu.redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: Wu Fengguang Cc: Andrew Morton , LKML , "linux-mm@kvack.org" , Matt Mackall , Ingo Molnar , Al Viro , "peterz@infradead.org" List-ID: On Sat, 2009-05-02 at 16:04 +0800, Wu Fengguang wrote: > On Sat, May 02, 2009 at 10:25:15AM +0800, Wu Fengguang wrote: > > Eric: this patch worked for me. Till now it has undergone many read, > > write, reboot, halt cycles without triggering the lockdep warnings :-) > > Bad news: the warning turns up again: > > [12979.538333] nfsd: last server has exited, flushing export cache > [12982.962058] > [12982.962062] ====================================================== > [12982.965486] [ INFO: RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected ] > [12982.965486] 2.6.30-rc2-next-20090417 #218 > [12982.965486] ------------------------------------------------------ > [12982.965486] umount/3574 [HC0[0]:SC0[0]:HE1:SE1] is trying to acquire: > [12982.965486] (&inode->inotify_mutex){+.+.+.}, at: [] inotify_unmount_inodes+0xda/0x1f0 > [12982.965486] > [12982.965486] and this task is already holding: > [12982.965486] (iprune_mutex){+.+.-.}, at: [] invalidate_inodes+0x3a/0x170 > [12982.965486] which would create a new lock dependency: > [12982.965486] (iprune_mutex){+.+.-.} -> (&inode->inotify_mutex){+.+.+.} > [12982.965486] > [12982.965486] but this new dependency connects a RECLAIM_FS-irq-safe lock: > [12982.965486] (iprune_mutex){+.+.-.} > [12982.965486] ... which became RECLAIM_FS-irq-safe at: > [12982.965486] [] __lock_acquire+0xc62/0x1ae0 > [12982.965486] [] lock_acquire+0xe1/0x120 > [12982.965486] [] mutex_lock_nested+0x63/0x420 > [12982.965486] [] shrink_icache_memory+0x84/0x300 > [12982.965486] [] shrink_slab+0x125/0x180 > [12982.965486] [] try_to_free_pages+0x276/0x400 > [12982.965486] [] __alloc_pages_internal+0x2b6/0x650 > [12982.965486] [] alloc_pages_current+0x8c/0xe0 > [12982.965486] [] __page_cache_alloc+0x10/0x20 > [12982.965486] [] __do_page_cache_readahead+0x11d/0x260 > [12982.965486] [] ondemand_readahead+0x1cb/0x250 > [12982.965486] [] page_cache_async_readahead+0xa9/0xc0 > [12982.965486] [] generic_file_aio_read+0x493/0x7c0 > [12982.965486] [] do_sync_read+0xf9/0x140 > [12982.965486] [] vfs_read+0x113/0x1d0 > [12982.965486] [] sys_read+0x57/0xb0 > [12982.965486] [] system_call_fastpath+0x16/0x1b > [12982.965486] [] 0xffffffffffffffff > [12982.965486] > [12982.965486] to a RECLAIM_FS-irq-unsafe lock: > [12982.965486] (&inode->inotify_mutex){+.+.+.} > [12982.965486] ... which became RECLAIM_FS-irq-unsafe at: > [12982.965486] ... [] mark_held_locks+0x68/0x90 > [12982.965486] [] lockdep_trace_alloc+0xf5/0x100 > [12982.965486] [] __kmalloc_node+0x31/0x1e0 > [12982.965486] [] kernel_event+0xe2/0x190 > [12982.965486] [] inotify_dev_queue_event+0x126/0x230 > [12982.965486] [] inotify_inode_queue_event+0xc6/0x110 > [12982.965486] [] vfs_create+0xcd/0x140 > [12982.965486] [] do_filp_open+0x88d/0xa20 > [12982.965486] [] do_sys_open+0x98/0x140 > [12982.965486] [] sys_open+0x20/0x30 > [12982.965486] [] system_call_fastpath+0x16/0x1b > [12982.965486] [] 0xffffffffffffffff So this is a completely different message than the original report, and one that is kind of cool and interesting. I think it could be triggered today. Again I think it's a false positive, since the inodes in question are being kicked out of kernel because the fs is being unmounted, but I'll poke someone to make sure I understand what lockdep is telling me and we can shut this one up too if we care.... -Eric -- 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