Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755978AbcCUXGq (ORCPT ); Mon, 21 Mar 2016 19:06:46 -0400 Received: from a.ns.miles-group.at ([95.130.255.143]:11949 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750937AbcCUXGp (ORCPT ); Mon, 21 Mar 2016 19:06:45 -0400 Subject: Re: Page migration issue with UBIFS To: Andrew Morton 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> <20160321160001.7598804306da8af40d82edc1@linux-foundation.org> 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 , Sasha Levin , Joonsoo Kim , rvaswani@codeaurora.org, "Luck, Tony" , Shailendra Verma , s.strogin@partner.samsung.com From: Richard Weinberger Message-ID: <56F07E7B.30700@nod.at> Date: Tue, 22 Mar 2016 00:06:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20160321160001.7598804306da8af40d82edc1@linux-foundation.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4484 Lines: 75 Am 22.03.2016 um 00:00 schrieb Andrew Morton: > On Wed, 16 Mar 2016 21:47:20 +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. >> > > The above says "PagePrivate was still set", and UBIFS does muck with > PagePrivate. Perhaps the fs isn't clearing things up in all the right > places. This is not the original splat. It is the output after applying a non-functional patch from Kirill. Thanks, //richard