Re: [PATCH 1/5] mm: tracking shared dirty pages

[Andrew Morton <akpm@osdl.org>]

On Wed, 28 Jun 2006 20:49:42 +0100 (BST)
Hugh Dickins <hugh@veritas.com> wrote:

> On Tue, 27 Jun 2006, Andrew Morton wrote:
> > Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > >
> > > Tracking of dirty pages in shared writeable mmap()s.
> > 
> > I mangled this a bit to fit it on top of Christoph's vm counters rewrite
> > (mm/page-writeback.c).
> > 
> > I worry about the changes to __set_page_dirty_nobuffers() and
> > test_clear_page_dirty().
> > 
> > They both already require that the page be locked (or that the
> > address_space be otherwise pinned).  But I'm not sure we get that right at
> > present.  With these changes, our exposure to that gets worse, and we
> > additionally are exposed to the possibility of the page itself being
> > reclaimed, and not just the address_space.
> > 
> > So ho hum.  I'll stick this:
> > 
> > --- a/mm/page-writeback.c~mm-tracking-shared-dirty-pages-checks
> > +++ a/mm/page-writeback.c
> > @@ -625,6 +625,7 @@ EXPORT_SYMBOL(write_one_page);
> >   */
> >  int __set_page_dirty_nobuffers(struct page *page)
> >  {
> > +	WARN_ON_ONCE(!PageLocked(page));
> 
> I expect this warning to fire: __set_page_dirty_nobuffers is very
> careful about page->mapping, it knows it might change precisely
> because we often don't have PageLocked here.

Yes, that's misplaced.  It was a consequence of me incorrectly fixing a
reject storm.

> >  	if (!TestSetPageDirty(page)) {
> >  		struct address_space *mapping = page_mapping(page);
> >  		struct address_space *mapping2;
> > @@ -722,6 +723,7 @@ int test_clear_page_dirty(struct page *p
> >  	struct address_space *mapping = page_mapping(page);
> >  	unsigned long flags;
> >  
> > +	WARN_ON_ONCE(!PageLocked(page));
> 
> I don't expect this warning to fire: I checked a month or two ago,
> and just checked again, I believe all paths have PageLocked here.
> If not, we certainly do want to know about it.

I've fixed it all up now and all is quiet. Looks OK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/