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. > > > > > 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() path > > line 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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>