On Tue, 14 Jun 2011 00:49:24 +0200 Jan Kara <jack@xxxxxxx> wrote: > > > people find that nicer. That place really looks like the only one which > > > depends on nrpages being consistent and uptodate. > > > > That seems a cleaner way of avoiding one manifestation of the bug. > OK. > > > But what *is* the bug? That we've made nrpages incoherent with the > > state of the tree? Or is it simply that the rule has always been "you > > must hold tree_lock to access nrpages", and the rcuification exposed > > that? > > > > I want to actually fix this stuff up and get a good clear design which > > we can describe and understand. No band-aids, please. Not in here. > OK, I belive the rule is "you must hold tree_lock to access nrpages" but > there are plenty of places which don't hold tree_lock and still peek at > nrpages to see if they have anything to do (and they were there even before > radix tree was rcuified). These are inherently racy and usually they don't > care - but possibly each such place should carry a comment explaining why > this racy check does not matter... OK, but it's weird and unexpected that a call to truncate_inode_pages(everything) can return with nrpages non-zero. Worth documenting this somewhere? And mention the behaviour/requirement at the nrpages definition site? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>