From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756851Ab0CPGmP (ORCPT ); Tue, 16 Mar 2010 02:42:15 -0400 Received: from cantor.suse.de ([195.135.220.2]:47493 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751621Ab0CPGmO (ORCPT ); Tue, 16 Mar 2010 02:42:14 -0400 Date: Tue, 16 Mar 2010 17:42:09 +1100 From: Nick Piggin To: Ingo Molnar Cc: Peter Zijlstra , Andrew Morton , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner Subject: Re: [rfc][patch] mm: lockdep page lock Message-ID: <20100316064209.GK2869@laptop> References: <20100315155859.GE2869@laptop> <20100316062032.GB22651@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100316062032.GB22651@elte.hu> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 16, 2010 at 07:20:32AM +0100, Ingo Molnar wrote: > > * Nick Piggin wrote: > > > Page lock has very complex dependencies, so it would be really nice to add > > lockdep support for it. > > Just wondering - has your patch shown any suspect areas of code already, in > the testing you did? Not yet. Although I only did basic stress testing with tmpfs and ext3 so far. It would get even further useful for fs developers combined with annotating more bit locks like buffer lock. BTW. I tried adding a might_fault() under page lock to see the infamous old page_lock -> mmap_sem deadlock, but it didn't warn. Explicitly doing a down_write/up_write of mmap_sem did warn. But it took a while to build the required chains, so I may have just been unlucky. > Maybe it should be test-driven for a while, in a non-append-only tree such as > -mm, to see whether it's finding real bugs. I think it should be very useful for filesystem developers. It doesn't seem too intrusive (and I will make it less so, by not open-coding the mutex_release/mutex_acquire pairs when changing page mapping). Filesystems and mm/vfs/fs lock interactions may be the most complex in the kernel... If you are worried about struct page bloat, it's already getting bloated by ptl spinlock in there. But it could always be configurable. No it isn't ready for -mm yet, let alone an append-only tree, I just wanted to get opinions from mm and fs (and lockdep) people. Thanks, Nick