Re: UBIFS assert failed in ubifs_set_page_dirty at 1421
From: Kirill A. Shutemov <hidden>
Date: 2014-11-20 12:30:11
Also in:
linux-fsdevel
On Fri, Nov 07, 2014 at 10:22:38AM +0800, hujianyang wrote:
Hi, I think we found the cause of this problem. We enable CONFIG_CMA in our config file. This feature seems to allocate a contiguous memory for caller. If some pages in this contiguous area are used by other modules, like UBIFS, CMA will migrate these pages to other place. This operation should be transparent to the user of old pages. But it is *not true* for UBIFS.quoted
1. UBIFS wants to make sure that no one marks UBIFS-backed pages (and actually inodes too) as dirty directly. UBIFS wants everyone to ask UBIFS to mark a page as dirty. 2. This is because for every dirty page, UBIFS needs to reserve certain amount of space on the flash media, because all writes are out-of-place, even when you are changing an existing file. 3. There are exactly 2 places where UBIFS-backed pages may be marked as dirty: a) ubifs_write_end() [->wirte_end] - the file write path b) ubifs_page_mkwrite() [->page_mkwirte] - the file mmap() pathline 1160, func try_to_unmap_one() in mm/rmap.c "" /* Move the dirty bit to the physical page now the pte is gone. */ if (pte_dirty(pteval)) set_page_dirty(page); "" Here, If the pte of a page is dirty, a directly set_page_dirty() is performed and hurt the internal logic of UBIFS.
If the pte is dirty it must be writable too. And to make pte writable ->page_mkwrite() must be called. So it should work fine.. Could you check if the pteval is pte_write() by the time? And could you provide what says dump_page(page) and dump_vma(vma) while you are there? -- Kirill A. Shutemov -- 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>