Re: UBIFS assert failed in ubifs_set_page_dirty at 1421

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

 



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>




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