mm: lockdep page lock
in [Kernel]
|
Prev: exec: replace call_usermodehelper_pipe with use of umh init function and resolve limit
Next: Staging: dream: generic_gpio: Use linux instead of asm uaccess.h
From: Peter Zijlstra on 24 Mar 2010 09:30 On Tue, 2010-03-16 at 13:21 +1100, Nick Piggin wrote: > > > Agreed (btw. Peter is there any way to turn lock debugging back on? > it's annoying when cpufreq hotplug code or something early breaks and > you have to reboot in order to do any testing). Not really, the only way to do that is to get the full system back into a known (zero) lock state and then fully reset the lockdep state. It might be possible using the freezer, but I haven't really looked at that, its usually simpler to simply fix the offending code or simply not build it in your kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 24 Mar 2010 10:00 On Tue, 2010-03-16 at 13:21 +1100, Nick Piggin wrote: > > locking rule here is that we always lock pages in index increasing order. I > > don't think lockdep will be able to handle something like that. Probably we > > can just avoid lockdep checking in these functions (or just acquire the > > page lock class for the first page) but definitely there will be some > > You are right, I don't think lockdep would work with that, so just > checking the lock for the first page should be better than nothing. > It might require some lockdep support in order to add context so it > doesn't go mad when unlock_page is called (would rather not add any > page flags to track that). > > If we were really clever and able to get back to the address of > struct page that _is_ holding the lock, we could just do a simple > check to ensure its index is < the index of the page we are trying > to take. > > That would give reasonable nesting checking without requiring lockdep > to track new chains for every page (obviously not feasible). Right, so lockdep does indeed not fancy such recursion things. Since the page frames are static you could basically make each lock its own class, but that will run lockdep out of chain storage real quick. Another thing you can do is look at spin_lock_nest_lock() which basically refcounts the class, you could do something like that for the page frame class, where you teach lockdep about the index rule. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Nick Piggin on 25 Mar 2010 01:40 On Wed, Mar 24, 2010 at 02:28:11PM +0100, Peter Zijlstra wrote: > On Tue, 2010-03-16 at 13:21 +1100, Nick Piggin wrote: > > > > > > Agreed (btw. Peter is there any way to turn lock debugging back on? > > it's annoying when cpufreq hotplug code or something early breaks and > > you have to reboot in order to do any testing). > > Not really, the only way to do that is to get the full system back into > a known (zero) lock state and then fully reset the lockdep state. > > It might be possible using the freezer, but I haven't really looked at > that, its usually simpler to simply fix the offending code or simply not > build it in your kernel. Right, but sometimes that is not possible (or you don't want to turn off cpufreq). I guess you could have an option to NOT turn it off in the first place. You could just turn off warnings, but leave everything else running, couldn't you? And then the option would just be to turn the printing back on. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 25 Mar 2010 05:50 On Thu, 2010-03-25 at 16:36 +1100, Nick Piggin wrote: > On Wed, Mar 24, 2010 at 02:28:11PM +0100, Peter Zijlstra wrote: > > On Tue, 2010-03-16 at 13:21 +1100, Nick Piggin wrote: > > > > > > > > > Agreed (btw. Peter is there any way to turn lock debugging back on? > > > it's annoying when cpufreq hotplug code or something early breaks and > > > you have to reboot in order to do any testing). > > > > Not really, the only way to do that is to get the full system back into > > a known (zero) lock state and then fully reset the lockdep state. > > > > It might be possible using the freezer, but I haven't really looked at > > that, its usually simpler to simply fix the offending code or simply not > > build it in your kernel. > > Right, but sometimes that is not possible (or you don't want to > turn off cpufreq). I guess you could have an option to NOT turn > it off in the first place. You could just turn off warnings, but > leave everything else running, couldn't you? > > And then the option would just be to turn the printing back on. Well, once there are cycles in the class graph you could end up finding that cycle again and again. So the easiest option is to simply bail after printing the acquisition that established the cycle. Alternatively you'd have to undo the cycle creation and somehow mark a class as bad and ignore it afterwards, which of course carries the risk that you'll not detect other cycles which would depend on that class. You could do as you suggest, but I would not trust the answers you get after that because you already have cycles in the graph so interpreting the things gets more and more interesting. So non of the options really work well, and fixing, reverting or simply not building is by far the easier thing to do. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jamie Lokier on 25 Mar 2010 23:20
Peter Zijlstra wrote: > On Tue, 2010-03-16 at 13:21 +1100, Nick Piggin wrote: > > > > > > Agreed (btw. Peter is there any way to turn lock debugging back on? > > it's annoying when cpufreq hotplug code or something early breaks and > > you have to reboot in order to do any testing). > > Not really, the only way to do that is to get the full system back into > a known (zero) lock state and then fully reset the lockdep state. How about: Set a variable nr_pending = number of CPUs, run a task on each CPU which disables interrupts, atomically decrements nr_pending and then spins waiting for it to become negative (raw, not counted in lockdep), and whichever one takes it to zero, that task knows there are no locks held, and can reset the lockdep state. Then sets it to -1 to wake everyone. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |