public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Nikhilesh Reddy <reddyn@codeaurora.org>
To: Richard Weinberger <richard@nod.at>
Cc: linux-mtd@lists.infradead.org
Subject: Re: issue with ubi_wl_put_peb
Date: Tue, 30 Aug 2016 10:53:57 -0700	[thread overview]
Message-ID: <57C5C835.6080900@codeaurora.org> (raw)
In-Reply-To: <19dc6d1c-30fb-737e-7d7e-da503a25e9f4@nod.at>

On Wed 24 Aug 2016 01:48:29 PM PDT, Richard Weinberger wrote:
> Nikhilesh Reddy,
>
> On 23.08.2016 20:55, Nikhilesh Reddy wrote:
>> Hi
>>
>>
>> I am currently running into a hard to reproduce issue( takes upto a week to reproduce) with ubi_wl_put_peb.
>>
>> I would appreciate any help you can give me.
>>
>> In the following stack
>> -000|__list_del_entry()
>> -001|list_del()
>> -002|prot_queue_del()
>> -003|ubi_wl_put_peb()
>> -004|ubi_eba_unmap_leb()
>> -005|ubifs_leb_unmap()
>> -006|ubifs_gc_start_commit()
>> -007|do_commit()
>> -008|run_bg_commit(inline)
>> -008|ubifs_bg_thread()
>> -009|kthread()
>>
>> This issue was seen with CONFIG_DEBUG_LIST=y
>>
>> What we see is that the wl entry that is being put is not in the protection queue but seems to be in free/used trees.
>
> So, you trigger a list assert?
> Please share the kernel log.
>
>> In the code  below:
>> http://git.infradead.org/linux-ubifs.git/blob/HEAD:/drivers/mtd/ubi/wl.c#l1231
>>
>> We see that the the wl_entry is checked to be in used/scrub and erroneous trees .. and then it simply assumes that it is in the protection queue if it is not in any of the rb trees.
>>
>> There appears to be a race where the  wl_entry is being put before it actually has a chance to be inserted into the protection queue.
>>
>> This seems to occur when ubi_io_write_vid_hdr takes long to write the VID header.
>>
>>
>> I noticed that a check for a similar situation is http://git.infradead.org/linux-ubifs.git/blob/HEAD:/drivers/mtd/ubi/wl.c#l761
>>
>> Is the same check needed in the case of ubi_wl_put_peb as well?
>>
>> Can you please tell me if this sounds like a known issue?
>>
>> I am a little lost on when |ubi_eba_unmap_leb would be called before the PEB has a chance to be inserted into a another tree from the free tree.
>>
>> I would be grateful any pointers that you can give me so i can get to the root cause.
>
> Hmmmm, is Fastmap involved?
>
> Thanks,
> //richard

Hi
Actually  FASTMAP was not involved.
This issue is pretty hard to reproduce ... just had reports of one 
instance where this occured.
If i see it again i will try to get all the logs.

Thanks So much for your help

--
Thanks
Nikhilesh Reddy

Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,
a Linux Foundation Collaborative Project.

  reply	other threads:[~2016-08-30 17:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-23 18:55 issue with ubi_wl_put_peb Nikhilesh Reddy
2016-08-24 20:48 ` Richard Weinberger
2016-08-30 17:53   ` Nikhilesh Reddy [this message]
2016-09-01  9:13     ` Richard Weinberger

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=57C5C835.6080900@codeaurora.org \
    --to=reddyn@codeaurora.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard@nod.at \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox