Re: [PATCH v2] UBIFS: Fix assert failed in ubifs_set_page_dirty

["Dolev Raviv" <draviv@codeaurora.org>]

Hi Hu, Thanks allot for your help.
> 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.

You are right the version is v3.10 and I do hit the
"ubifs_assert(0)"

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

Wouldn't then the assertion in the previous line fail?
I dove into the code, and I understood there probably isn't any real
connection between the to.
I do appreciate you took the time to answer me :) .

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

I did notice, at least once, assertion failure:
[ 4445.102863] UBIFS: un-mount UBI device 1, volume 0
[ 4445.106627] UBIFS assert failed in ubifs_put_super at 1775 (pid 10416)

But, this error happens only significantly later ~2 hours.

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

At the moment I hit this randomly when stressing the system.
I use a stress test that run parallel IOzone and lmdd benchmark, each
100MB (out of ~217MB free)



Wouldn't then the assertion in the previous line fail?
I dove into the code, and I understood there probably isn't any real
connection between the to.
I do appreciate you took the time to answer me . :-)

Thanks,
Dolev
-- 
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation