On Mon, Nov 15, 2010 at 01:23:14PM -0500, Christoph Hellwig wrote:
> On Sun, Nov 14, 2010 at 11:12:22PM +0100, Andrea Arcangeli wrote:
> > +static int btree_migratepage(struct address_space *mapping,
> > + struct page *newpage, struct page *page)
> > +{
> > + /*
> > + * we can't safely write a btree page from here,
> > + * we haven't done the locking hook
> > + */
> > + if (PageDirty(page))
> > + return -EAGAIN;
> >
> > fallback_migrate_page would call writeout() which is apparently not
> > ok in btrfs for locking issues leading to corruption.
>
> Hmm, it seems the issue for that particular problem is indeedin btrfs.
I've been reading the writeout() in mm/migrate.c and I wonder if maybe
that should have been WB_SYNC_ALL or if we miss a
wait_on_page_writeback in after ->writepage() returns? Can you have a
look there? We check the PG_writeback bit when the page is not dirty
(well before fallback_migrate_page is called), but after calling
writeout() we don't return to wait on PG_writeback. We make sure to
hold the page lock after ->writepage returns but that doesn't mean
PG_writeback isn't still set.
> If it needs external locking for writing out data it should not
> implement ->writepage to start with. Chris, can you explain what's
> going on with the btree code? It's pretty funny both in the
> btree_writepage which goes directly into extent_write_full_page
> if PF_MEMALLOC is not set, but otherwise does much more complicated
> work, and also in btree_writepages which skips various WB_SYNC_NONE,
> including the very weird check for for_kupdate.
>
> What's the story behing all this and the corruption that Andrea found?
>
> > > Btw, what codepath does THP call migrate_pages from? If you don't
> > > use an explicit thread writeout will be a no-op on btrfs and XFS, too.
> >
> > THP never calls migrate_pages, it's memory compaction that calls it
> > from inside alloc_pages(order=9). It got noticed only with THP because
> > it makes more frequent hugepage allocations than nr_hugepages in
> > hugetlbfs (and maybe there are more THP users already).
>
> Well, s/THP/compaction/ and the same problem applies. The modern
> filesystem all have stopped from writeback happening either at all
> or at least for the delalloc case from direct reclaim. Calling
> into this code from alloc_pages for filesystem backed pages is thus
> rather pointless.
Compaction practically only happens in the context of the task
allocating memory (in my tree it is also used by kswapd). Not
immediate to ask a separate daemon to invoke it. Not sure why this
should screw delalloc. Compaction isn't freeing any memory at all,
it's not reclaim. It just defragments and moves stuff around and it
may have to write dirty pages to do so.
--
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 policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>