All of lore.kernel.org
 help / color / mirror / Atom feed
From: hujianyang <hujianyang@huawei.com>
To: Dolev Raviv <draviv@codeaurora.org>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH v2] UBIFS: Fix assert failed in ubifs_set_page_dirty
Date: Sun, 4 May 2014 14:38:35 +0800	[thread overview]
Message-ID: <5365E06B.8080300@huawei.com> (raw)
In-Reply-To: <3921496816192fe04ed3cdbb562fc6d8.squirrel@www.codeaurora.org>

Hi, Dolev

On 2014/4/30 21:48, Dolev Raviv wrote:
> Hi Hujianyang and Laurence,
> I'm hitting an assertion in very similar code during the callback
> ubifs_releasepage(). I'm quite new to this code area, and currently diving
> in to understanding the race you described (before I attempt to look at
> the patch).
> 
> I was wondering if this assertion is related?
> 
> [  862.695278] UBIFS assert failed in ubifs_releasepage at 1434 (pid 11088)

What's your kernel version? Because in v3.15 and v3.10, line 1434
present different assertion.

I think you probably hit:

"ubifs_assert(0)"

static int ubifs_releasepage(struct page *page, gfp_t unused_gfp_flags)
{
        /*
         * An attempt to release a dirty page without budgeting for it - should
         * not happen.
         */
        if (PageWriteback(page))
                return 0;
        ubifs_assert(PagePrivate(page));
        ubifs_assert(0);                          <- v3.10 line 1434
        ClearPagePrivate(page);
        ClearPageChecked(page);
        return 1;
}


Page_Private bit seems to indicate page is budgeted in UBIFS. Dropping
caches performs with page lock and just deals with pages which are not
dirty. Then, if page_private bit is set, vfs performs ->releasepage at
try_to_release_page.

Maybe some explanation of this assert failed is that there is a private
(budgeted) but not dirty page in your page caches.

I think it is not related to my race because pages can just remain
in 3 states at fsync and mmap:

1) Dirty, Private
2) Not Dirty, Not Private
3) Dirty, Not Private (wrong condition)

Did you get some more assert failed after this? If you umount UBIFS,
ubifs_put_super will check the budget info, and I think you should
hit some assertion there.

Do you have a simply way to reproduce this assert failed?


Hu

  reply	other threads:[~2014-05-04  6:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-26  9:25 [PATCH RFC] UBIFS: Fix assert failed in ubifs_set_page_dirty hujianyang
2014-04-30  6:06 ` [PATCH v2] " hujianyang
2014-04-30 12:18   ` Laurence Withers
2014-04-30 13:48     ` Dolev Raviv
2014-05-04  6:38       ` hujianyang [this message]
2014-05-04 11:54         ` Dolev Raviv
2014-05-05  7:07     ` Artem Bityutskiy
2014-05-05 11:50       ` Laurence Withers
2014-05-05  7:02   ` Artem Bityutskiy
2014-05-05  7:16     ` Artem Bityutskiy
2014-05-05  7:30       ` hujianyang

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=5365E06B.8080300@huawei.com \
    --to=hujianyang@huawei.com \
    --cc=draviv@codeaurora.org \
    --cc=linux-mtd@lists.infradead.org \
    /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.