Linux-mtd Archive on lore.kernel.org
 help / color / Atom feed
From: Hou Tao <houtao1@huawei.com>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
	linux-mtd@lists.infradead.org,
	Adrian Hunter <ext-adrian.hunter@nokia.com>,
	Carson.Li1@unisoc.com
Subject: Re: [PATCH v3 2/2] ubifs: read node from wbuf when it fully sits in wbuf
Date: Wed, 1 Jul 2020 09:15:42 +0800
Message-ID: <9f583ac6-2046-47e4-8327-33a488c1f138@huawei.com> (raw)
In-Reply-To: <CAFLxGvzWYp7=6F7PY0-dxxSCPrN4L2H6tzE913N9rKsaChnoWg@mail.gmail.com>

Hi,

On 2020/3/17 6:21, Richard Weinberger wrote:
> Hou Tao,
> 
> On Thu, Mar 5, 2020 at 10:15 AM Hou Tao <houtao1@huawei.com> wrote:
>>
>> Carson Li Reports the following error:
>>
>>  UBIFS error: ubifs_read_node_wbuf: expected node type 0
>>  Not a node, first 24 bytes:
>>  Kernel panic - not syncing
>>  CPU: 1 PID: 943 Comm: http-thread 4.4.83 #1
>>    panic+0x70/0x1e4
>>    ubifs_dump_node+0x6c/0x9a0
>>    ubifs_read_node_wbuf+0x350/0x384
>>    ubifs_tnc_read_node+0x54/0x214
>>    ubifs_tnc_locate+0x118/0x1b4
>>    ubifs_iget+0xb8/0x68c
>>    ubifs_lookup+0x1b4/0x258
>>    lookup_real+0x30/0x4c
>>    __lookup_hash+0x34/0x3c
>>    walk_component+0xec/0x2a0
>>    path_lookupat+0x80/0xfc
>>    filename_lookup+0x5c/0xfc
>>    vfs_fstatat+0x4c/0x9c
>>    SyS_stat64+0x14/0x30
>>    ret_fast_syscall+0x0/0x34
>>
>> It seems the LEB used as DATA journal head is GC'ed, and ubifs_tnc_locate()
>> read an invalid node. But now the property of journal head LEB has
>> LPROPS_TAKEN flag set and GC will skip these LEBs.
>>
>> The actual situation of the problem is the LEB is GCed, freed and then
>> reused as journal head, and finally ubifs_tnc_locate() reads
>> an invalid node. And it can be reproduced by the following steps:
>> * create 128 empty files
>> * overwrite 8 files in backgroup repeatedly to trigger GC
>> * drop inode cache and stat these 128 empty files repeatedly
>>
>> We can simply fix the problem by removing the optimization of reading
>> wbuf when possible. But because taking spin lock and memcpying from
>> wbuf is much less time-consuming than reading from MTD device, so we fix
>> the logic of wbuf reading instead.
> 
> I'm digging now into that issue. Did you also experiment with reading while
> tnc_mutex is locked? So, no race at all (having safely = 1 by default).
> Just to make sure we don't fix an no longer needed optimization.
>> The code is already anything but trivial and adding more code makes me
> nervous.
> 
Sorry for the late reply. I'm fine if we remove the read-wbuf optimization,
but I need to check the code firstly, running the reproducing program, and lastly
writing a xfstest for it.

Regards,
Tao

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05  9:22 [PATCH v3 0/2] fix potential race between ubifs_tnc_locate() and GC Hou Tao
2020-03-05  9:22 ` [PATCH v3 1/2] ubifs: factor out helper ubifs_check_node_buf() Hou Tao
2020-03-05  9:22 ` [PATCH v3 2/2] ubifs: read node from wbuf when it fully sits in wbuf Hou Tao
2020-03-16 22:21   ` Richard Weinberger
2020-07-01  1:15     ` Hou Tao [this message]
2020-03-16 22:33   ` Richard Weinberger
2020-03-18  1:57     ` Hou Tao

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=9f583ac6-2046-47e4-8327-33a488c1f138@huawei.com \
    --to=houtao1@huawei.com \
    --cc=Carson.Li1@unisoc.com \
    --cc=ext-adrian.hunter@nokia.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard.weinberger@gmail.com \
    --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

Linux-mtd Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mtd/0 linux-mtd/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mtd linux-mtd/ https://lore.kernel.org/linux-mtd \
		linux-mtd@lists.infradead.org
	public-inbox-index linux-mtd

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-mtd


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git