On Wed, 18 Mar 2009 14:27:32 -0400 Eric Paris <eparis@xxxxxxxxxx> wrote: > I think this is a bandaide to shut up lockdep. I could either figure > out lockdep classes and figure out how to reclassify inotify locks since > I believe Nick is correct when he says inotify watches pin the inode in > core so memory pressure can't evict it. It's pretty sad to degrading the strength of the memory allocation just to squish a lockdep report. > I don't want to do that as I > think the real fix is my next generation fsnotify which does zero > allocations under locks and so everything can be GFP_KERNEL. I assume that's the 13-patch series further down in my todo pile. Perhaps this workaround is suitable for 2.6.29.x, or 2.6.30 if the 13-patch-series was too late. But do we care enough? > I'm > posting this as it is clearly safe and should fix the issue. > > http://marc.info/?l=linux-kernel&m=123617147432377&w=2 > > includes a lockdep warning that shows while we are reclaiming FS memory > and inode may get evicted which generates an IN_IGNORED message. Half > of that code path already used GFP_NOFS but a second allocation to store > the filename was using GFP_KERNEL. As a precaution I also moved the > audit handle_event code path to use GFP_NOFS. > > This is much the same as the precaution in f04b30de3c82528 which did > something similar. > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
