All of lore.kernel.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 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.