From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com [209.85.192.178]) by kanga.kvack.org (Postfix) with ESMTP id 357E56B0005 for ; Thu, 17 Mar 2016 03:10:44 -0400 (EDT) Received: by mail-pf0-f178.google.com with SMTP id x3so108356768pfb.1 for ; Thu, 17 Mar 2016 00:10:44 -0700 (PDT) Received: from lgeamrelo11.lge.com (LGEAMRELO11.lge.com. [156.147.23.51]) by mx.google.com with ESMTP id ta4si1974963pac.193.2016.03.17.00.10.42 for ; Thu, 17 Mar 2016 00:10:43 -0700 (PDT) Date: Thu, 17 Mar 2016 16:11:55 +0900 From: Joonsoo Kim Subject: Re: Page migration issue with UBIFS Message-ID: <20160317071155.GB10315@js1304-P5Q-DELUXE> References: <56E8192B.5030008@nod.at> <20160315151727.GA16462@node.shutemov.name> <56E82B18.9040807@nod.at> <20160315153744.GB28522@infradead.org> <56E8985A.1020509@nod.at> <20160316142156.GA23595@node.shutemov.name> <20160316142729.GA125481@black.fi.intel.com> <56E9C658.1020903@nod.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56E9C658.1020903@nod.at> Sender: owner-linux-mm@kvack.org List-ID: To: Richard Weinberger Cc: "Kirill A. Shutemov" , "Kirill A. Shutemov" , Christoph Hellwig , linux-fsdevel , "linux-mtd@lists.infradead.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Boris Brezillon , Maxime Ripard , David Gstir , Dave Chinner , Artem Bityutskiy , Alexander Kaplan , "akpm@linux-foundation.org" , Sasha Levin , rvaswani@codeaurora.org, "Luck, Tony" , Shailendra Verma , s.strogin@partner.samsung.com On Wed, Mar 16, 2016 at 09:47:20PM +0100, Richard Weinberger wrote: > Adding more CC's. > > Am 16.03.2016 um 15:27 schrieb Kirill A. Shutemov: > > On Wed, Mar 16, 2016 at 05:21:56PM +0300, Kirill A. Shutemov wrote: > >> On Wed, Mar 16, 2016 at 12:18:50AM +0100, Richard Weinberger wrote: > >>> Am 15.03.2016 um 16:37 schrieb Christoph Hellwig: > >>>> On Tue, Mar 15, 2016 at 04:32:40PM +0100, Richard Weinberger wrote: > >>>>>> Or if ->page_mkwrite() was called, why the page is not dirty? > >>>>> > >>>>> BTW: UBIFS does not implement ->migratepage(), could this be a problem? > >>>> > >>>> This might be the reason. I can't reall make sense of > >>>> buffer_migrate_page, but it seems to migrate buffer_head state to > >>>> the new page. > >>>> > >>>> I'd love to know why CMA even tries to migrate pages that don't have a > >>>> ->migratepage method, this seems incredibly dangerous to me. > >>> > >>> FYI, with a dummy ->migratepage() which returns only -EINVAL UBIFS does no > >>> longer explode upon page migration. > >>> Tomorrow I'll do more tests to make sure. > >> > >> Could you check if something like this would fix the issue. > > Nope. > > [ 108.080000] BUG: Bad page state in process drm-stress-test pfn:5c674 > [ 108.080000] page:deb8ce80 count:0 mapcount:0 mapping: (null) index:0x0 > [ 108.090000] flags: 0x810(dirty|private) > [ 108.100000] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set > [ 108.100000] bad because of flags: > [ 108.110000] flags: 0x800(private) > [ 108.110000] Modules linked in: > [ 108.120000] CPU: 0 PID: 1855 Comm: drm-stress-test Not tainted 4.4.4-gaae1ad1-dirty #14 > [ 108.120000] Hardware name: Allwinner sun4i/sun5i Families > [ 108.120000] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [ 108.120000] [] (show_stack) from [] (dump_stack+0x8c/0xa0) > [ 108.120000] [] (dump_stack) from [] (bad_page+0xcc/0x11c) > [ 108.120000] [] (bad_page) from [] (free_pages_prepare+0x22c/0x2f4) > [ 108.120000] [] (free_pages_prepare) from [] (free_hot_cold_page+0x34/0x194) > [ 108.120000] [] (free_hot_cold_page) from [] (free_hot_cold_page_list+0x48/0xdc) > [ 108.120000] [] (free_hot_cold_page_list) from [] (release_pages+0x1dc/0x224) > [ 108.120000] [] (release_pages) from [] (pagevec_lru_move_fn+0xe8/0xf8) > [ 108.120000] [] (pagevec_lru_move_fn) from [] (__lru_cache_add+0x60/0x88) > [ 108.120000] [] (__lru_cache_add) from [] (putback_lru_page+0x68/0xbc) > [ 108.120000] [] (putback_lru_page) from [] (migrate_pages+0x208/0x730) > [ 108.120000] [] (migrate_pages) from [] (alloc_contig_range+0x168/0x2f4) > [ 108.120000] [] (alloc_contig_range) from [] (cma_alloc+0x170/0x2c0) > [ 108.120000] [] (cma_alloc) from [] (__alloc_from_contiguous+0x38/0xd8) > [ 108.120000] [] (__alloc_from_contiguous) from [] (__dma_alloc+0x234/0x278) > [ 108.120000] [] (__dma_alloc) from [] (arm_dma_alloc+0x54/0x5c) > [ 108.120000] [] (arm_dma_alloc) from [] (drm_gem_cma_create+0x9c/0xf0) > [ 108.120000] [] (drm_gem_cma_create) from [] (drm_gem_cma_create_with_handle+0x1c/0xe8) > [ 108.120000] [] (drm_gem_cma_create_with_handle) from [] (drm_gem_cma_dumb_create+0x3c/0x48) > [ 108.120000] [] (drm_gem_cma_dumb_create) from [] (drm_ioctl+0x12c/0x440) > [ 108.120000] [] (drm_ioctl) from [] (do_vfs_ioctl+0x3f4/0x614) > [ 108.120000] [] (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) > [ 108.120000] [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x34) > > It is still not clear why UBIFS has to provide a >migratepage() and what the expected semantics > are. > What we know so far is that the fall back migration function is broken. I'm sure not only on UBIFS. > > Can CMA folks please clarify? :-) Hello, As you mentioned earlier, this issue would not be directly related to CMA. It looks like it is more general issue related to interaction between MM and FS. Your first error log shows that error happens when ubifs_set_page_dirty() is called in try_to_unmap_one() which also can be called by reclaimer (kswapd or direct reclaim). Quick search shows that problem also happens on reclaim. Is that fixed? http://www.spinics.net/lists/linux-fsdevel/msg79531.html I think that you need to CC other people who understand interaction between MM and FS perfectly. Sorry about not much helpful here. Thanks. -- 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/ . Don't email: email@kvack.org