Re: [PATCH] mm: Fix assertion mapping->nrpages == 0 in end_writeback()

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 14 Jun 2011 00:49:24 +0200
Jan Kara <jack@suse.cz> 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@kvack.org.  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@kvack.org"> email@kvack.org </a>