Re: Oops while rebalancing, now unmountable.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Nov 14, 2010 at 11:12:22PM +0100, Andrea Arcangeli wrote:
> I just wrote above that it can happen upstream without THP. It's not
> THP related at all. THP is the consumer, this is a problem in migrate
> that will trigger as well with migrate_pages or all other possible
> migration APIs.
> 
> If more people would be using hugetlbfs they would have noticed
> without THP.

Okay, it seems THP is really just the messenger for bad VM practices
here.

> +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.
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.

--
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>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]