All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: hujianyang <hujianyang@huawei.com>
Cc: Jijiagang <jijiagang@hisilicon.com>,
	dedekind1@gmail.com, Caizhiyong <caizhiyong@hisilicon.com>,
	"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
	linux-mm@kvack.org,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"Wanli \(welly\)" <welly.wan@hisilicon.com>
Subject: Re: UBIFS assert failed in ubifs_set_page_dirty at 1421
Date: Thu, 20 Nov 2014 14:30:11 +0200	[thread overview]
Message-ID: <20141120123011.GA9716@node.dhcp.inet.fi> (raw)
In-Reply-To: <545C2CEE.5020905@huawei.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: hujianyang <hujianyang@huawei.com>
Cc: dedekind1@gmail.com, Caizhiyong <caizhiyong@hisilicon.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	linux-mm@kvack.org, "Wanli (welly)" <welly.wan@hisilicon.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
	Jijiagang <jijiagang@hisilicon.com>
Subject: Re: UBIFS assert failed in ubifs_set_page_dirty at 1421
Date: Thu, 20 Nov 2014 14:30:11 +0200	[thread overview]
Message-ID: <20141120123011.GA9716@node.dhcp.inet.fi> (raw)
In-Reply-To: <545C2CEE.5020905@huawei.com>

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@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>

  reply	other threads:[~2014-11-20 12:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BE257DAADD2C0D439647A271332966573949EFEC@SZXEMA511-MBS.china.huawei.com>
2014-10-20 11:52 ` UBIFS assert failed in ubifs_set_page_dirty at 1421 Artem Bityutskiy
2014-10-20 11:55   ` Caizhiyong
2014-10-20 12:01   ` Caizhiyong
2014-10-20 13:11     ` Artem Bityutskiy
2014-10-20 13:11       ` Artem Bityutskiy
2014-10-20 13:11       ` Artem Bityutskiy
2014-10-21  2:30       ` Jijiagang
2014-10-21  2:30         ` Jijiagang
2014-10-21  3:38       ` Dave Chinner
2014-10-21  3:38         ` Dave Chinner
2014-10-21  3:38         ` Dave Chinner
2014-10-21  8:41         ` Jijiagang
2014-10-21  8:41           ` Jijiagang
2014-10-21  8:41           ` Jijiagang
2014-11-06  8:28       ` Jijiagang
2014-11-06  8:28         ` Jijiagang
2014-11-06  8:28         ` Jijiagang
2014-11-07  2:22       ` hujianyang
2014-11-07  2:22         ` hujianyang
2014-11-07  2:22         ` hujianyang
2014-11-20 12:30         ` Kirill A. Shutemov [this message]
2014-11-20 12:30           ` Kirill A. Shutemov
2014-11-24  2:59           ` Jijiagang
2014-11-24  2:59             ` Jijiagang
2014-11-24  2:59             ` Jijiagang
2014-11-24  9:10             ` Kirill A. Shutemov
2014-11-24  9:10               ` Kirill A. Shutemov
2014-11-24 10:20               ` Jijiagang
2014-11-24 10:20                 ` Jijiagang
2014-11-24 10:20                 ` Jijiagang
2014-11-24 13:27                 ` Kirill A. Shutemov
2014-11-24 13:27                   ` Kirill A. Shutemov
2014-10-22  3:38   ` hujianyang
2014-10-22  8:02     ` Artem Bityutskiy
2014-10-22  8:21       ` hujianyang
2014-10-22  9:30         ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141120123011.GA9716@node.dhcp.inet.fi \
    --to=kirill@shutemov.name \
    --cc=adrian.hunter@intel.com \
    --cc=caizhiyong@hisilicon.com \
    --cc=dedekind1@gmail.com \
    --cc=hujianyang@huawei.com \
    --cc=jijiagang@hisilicon.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=welly.wan@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.