On Tue, 14 Jun 2011 00:49:24 +0200 Jan Kara <[email protected]> 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? _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
