linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "李傲傲 (Carson Li1/9542)" <Carson.Li1@unisoc.com>
To: linux-mtd <linux-mtd@lists.infradead.org>,
	Richard Weinberger <richard@nod.at>
Subject: RE: ubifs: read bad node type in ubifs_tnc_read_wbuf
Date: Wed, 19 Feb 2020 12:03:47 +0000	[thread overview]
Message-ID: <c62bae00e0d741cc9be1752b139c42d6@shmbx04.spreadtrum.com> (raw)
In-Reply-To: 1741454272.21050.1579043778589.JavaMail.zimbra@nod.at

Hi Richard:
I am sorry that I had sent an email to the linux-mtd but find out
I did not copy to you. Now I resend it again, please kindly check it
and reply me.

>>LPROPS_TAKEN should avoid this.
>Is it possible that a commit finishes and removes the LPROPS_TAKEN flag?
>and when it is reused as a journal head, LPROPS_TAKEN flag is set again.

>>If possible, can you please check the lprobs of the affected LEBs?
>--------------------------------case 1----------------------------------------------
>jhead[GCHD].wbuf.lnum   = 195(found in TNC)
>jhead[DATAHD].wbuf.lnum  = 139(zbr passed to ubifs_tnc_read_node)

>struct ubifs_lprops =
>
>      free = 4096,
>      dirty = 123272,
>      flags = 16, //LPROPS_TAKEN
>      lnum = 195,
>      {
>        list = {
>          next = 0xcd1ad6d8,
>          prev = 0xcd1ad440
>        },
>        hpos = -853879080
>      }
>    }

>struct ubifs_lprops = {
>      free = 124944,
>      dirty = 0,
>      flags = 16, //LPROPS_TAKEN
>      lnum = 139,
>      {
>        list = {
>          next = 0xc8be96c0,
>          prev = 0xc90e99c8
>        },
>        hpos = -927033664
>      }
>    }

>one more information about the ubifs_bud rbtree:

>crash_arm> tree -t rbtree -o ubifs_bud.rb -N 0xcd196dd4 -s ubifs_bud.lnum
>cd196dc0
>  lnum = 195//jhead[GCHD]
>c89207c0
>  lnum = 60
>cd196fc0
>  lnum = 59
>c8bd5e40
>  lnum = 125
>c8935600
>  lnum = 97
>c2aafec0
>  lnum = 139//jhead[DATAHD]
>c8bb2140
>  lnum = 279//jhead[BASEHD]
>c8ee8d00
>  lnum = 239
>cd196980
>  lnum = 348
>--------------------------------------case 2----------------------------------------
>jhead[GCHD].wbuf.lnum   = 224(found in TNC)
>jhead[DATAHD].wbuf.lnum  = 54(zbr passed to ubifs_tnc_read_node)

>struct ubifs_lprops =
>{
>      free = 24576,
>      dirty = 127640,
>      flags = 16, //LPROPS_TAKEN
>      lnum = 224,
>      {
>        list = {
>          next = 0xc9014ec0,
>          prev = 0xc91ed0c0
>        },
>        hpos = -922661184
>      }
> }
>struct ubifs_lprops =
>{
>      free = 45952,
>      dirty = 0,
>      flags = 16, //LPROPS_TAKEN
>      lnum = 54,
>      {
>        list = {
>          next = 0xcd1d4328,
>          prev = 0xc90ea9c8
>        },
>        hpos = -853720280
>      }
>    }

>crash_arm> tree -t rbtree -o ubifs_bud.rb -N 0xc6afae14 -s ubifs_bud.lnum
>c6afae00
>  lnum = 88
>c8fa5540
>  lnum = 53//jhead[BASEHD]
>c916b500
>  lnum = 42
>c8f8b140
>  lnum = 62
>c2a953c0
>  lnum = 54//jhead[DATAHD]
>c916b480
>  lnum = 215
>c2ac0040
>  lnum = 120
>c916b400
>  lnum = 224//jhead[GCHD]
>c6b02f80
>  lnum = 271

>By the way, there is another timing the LEB might be garbage collected:
>>     A      |              B
>> --------------------------------------------------------------------------
>> ubifs_tnc_locate
>>   zbr->lnum = 54 (find in TNC)
>>     ubifs_get_wbuf(zbr->lnum = 54) is ture
>>          ubifs_tnc_read_node
>>                         ->GC(change zt->lnum to 224(GCHD) in _TNC_)
>>                         ->zbr->lnum = 54 becomes DATAHD
>>             ubifs_get_wbuf(zbr->lnum = 54 as the DATAHD) is ture again
>>             ubifs_read_node_wbuf
>> --------------------------------------------------------------------------

     A      |              B
 ---------------------------------------------------------------------------
>ubifs_tnc_locate
>   zbr->lnum = 54 (find in TNC)
>                         ->GC(change zt->lnum to 224(GCHD) in _TNC_)
>                         ->zbr->lnum = 54 becomes DATAHD
>     ubifs_get_wbuf(zbr->lnum = 54 as the DATAHD) is ture
>          ubifs_tnc_read_node
>             ubifs_get_wbuf(zbr->lnum = 54) is ture again
>             ubifs_read_node_wbuf
> ---------------------------------------------------------------------------

Thanks.
Carson
________________________________
 This email (including its attachments) is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Unauthorized use, dissemination, distribution or copying of this email or the information herein or taking any action in reliance on the contents of this email or the information herein, by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is strictly prohibited. If you are not the intended recipient, please do not read, copy, use or disclose any part of this e-mail to others. Please notify the sender immediately and permanently delete this e-mail and any attachments if you received it in error. Internet communications cannot be guaranteed to be timely, secure, error-free or virus-free. The sender does not accept liability for any errors or omissions.
本邮件及其附件具有保密性质,受法律保护不得泄露,仅发送给本邮件所指特定收件人。严禁非经授权使用、宣传、发布或复制本邮件或其内容。若非该特定收件人,请勿阅读、复制、 使用或披露本邮件的任何内容。若误收本邮件,请从系统中永久性删除本邮件及所有附件,并以回复邮件的方式即刻告知发件人。无法保证互联网通信及时、安全、无误或防毒。发件人对任何错漏均不承担责任。
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  parent reply	other threads:[~2020-02-19 12:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <e2d34800d72243ed85e8df63bb80f7ab@shmbx04.spreadtrum.com>
     [not found] ` <ce621148db0e4f9c80f32c348975663a@shmbx04.spreadtrum.com>
     [not found]   ` <ae16d475c0d24c1ba6ab18f1e766e928@shmbx04.spreadtrum.com>
     [not found]     ` <46e2f6ca11a442f38d476d4346e8034c@shmbx04.spreadtrum.com>
2020-01-12 23:48       ` ubifs: read bad node type in ubifs_tnc_read_wbuf Richard Weinberger
2020-01-14  1:09         ` 李傲傲 (Carson Li1/9542)
2020-01-14  8:09           ` Richard Weinberger
2020-01-14  8:28             ` 李傲傲 (Carson Li1/9542)
2020-01-14 11:01             ` 李傲傲 (Carson Li1/9542)
2020-01-14 23:16               ` Richard Weinberger
2020-01-16  0:54                 ` 李傲傲 (Carson Li1/9542)
2020-02-19 12:03                 ` 李傲傲 (Carson Li1/9542) [this message]
2020-02-26 12:11                   ` Hou Tao
2020-02-27  1:18                     ` 李傲傲 (Carson Li1/9542)
2020-02-27  6:34                       ` Hou Tao
2020-02-27  6:49                         ` 李傲傲 (Carson Li1/9542)
2020-03-02  1:39                           ` Hou Tao
2020-03-02  3:12                             ` 李傲傲 (Carson Li1/9542)
2020-03-02  6:35                               ` Hou Tao
2020-03-02  7:56                                 ` 李傲傲 (Carson Li1/9542)
2020-03-02 10:23                                   ` Hou Tao
2020-03-03  1:21                                     ` 李傲傲 (Carson Li1/9542)
2020-01-10  9:10 李傲傲 (Carson Li1/9542)

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=c62bae00e0d741cc9be1752b139c42d6@shmbx04.spreadtrum.com \
    --to=carson.li1@unisoc.com \
    --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;
as well as URLs for NNTP newsgroup(s).