Linux-mtd Archive on lore.kernel.org
 help / color / Atom feed
From: Hou Tao <houtao1@huawei.com>
To: Richard Weinberger <richard@nod.at>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 0/3] fixes for ubifs xattr operations
Date: Wed, 1 Jul 2020 09:11:35 +0800
Message-ID: <8ed3f848-a1d2-e1ce-a3b0-d4e6d2d12d9d@huawei.com> (raw)
In-Reply-To: <25305185.75764.1593522901565.JavaMail.zimbra@nod.at>

Hi,

On 2020/6/30 21:15, Richard Weinberger wrote:
> Tao,
> 
> ----- Ursprüngliche Mail -----
>> Von: "Hou Tao" <houtao1@huawei.com>
>> An: "richard" <richard@nod.at>, "linux-mtd" <linux-mtd@lists.infradead.org>
>> CC: "Hou Tao" <houtao1@huawei.com>
>> Gesendet: Dienstag, 30. Juni 2020 15:04:35
>> Betreff: [PATCH 0/3] fixes for ubifs xattr operations
> 
>> Hi,
>>
>> The patch set tries to fix the race between ubifs xattr read
>> operations and write operations.
>>
>> Now inode_lock() is acquired during xattr write ops (set & remove),
>> however no extra lock is taken in xattr read ops (list & get), and
>> it leads to three problems:
>>
>> (1) ubifs_listxattr() may incur memory corruption and assertion failure
>>
>> (2) ubifs_xattr_get() may incur assertion failure
>>
>> (3) ubifs_xattr_get() may return a stale xattr value
>>
>> To fix it, instead of adding a xattr-related rwsem for ubifs inode,
>> we decide to fix these problems simply and still do xattr read operation
>> locklessly. The major concern is that xattr read operations (list & get)
>> may return xattr names or values which is still in creation or removal
>> process, but we think that's OK because no stale name or value is
>> returned, just either the old ones or the new ones.
>>
>> Comments are weclome.
> 
> Thanks a lot for digging into this.
> Do you have a test for this? (xfstest prefered).
> 
The first two problem can be reproduced relatively easily, and the third problem
is hard to reproduce (I do it through injecting delay in xattr ops), so I will
add xfstests for the first two problem firstly, then I will try to add an xfstests
for the last one. Maybe we can add a thin "infrastructure" layer to inject delay.

> I'm a bit surprised that this can actually happen, I was under the impression
> that vfs cares about this.
> 
Most filesystems handle the race by adding a rw-semaphore, but I think we can
simply do in a "lockless" way.

Regards,
Tao

> Thanks,
> //richard
> .
> 

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

      reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30 13:04 Hou Tao
2020-06-30 13:04 ` [PATCH 1/3] ubifs: check the remaining name buffer during xattr list Hou Tao
2020-06-30 13:04 ` [PATCH 2/3] ubifs: protect assertion of xattr value size by ui_mutex during xattr get Hou Tao
2020-06-30 13:04 ` [PATCH 3/3] ubifs: ensure only one in-memory xattr inode is created Hou Tao
2020-06-30 13:15 ` [PATCH 0/3] fixes for ubifs xattr operations Richard Weinberger
2020-07-01  1:11   ` Hou Tao [this message]

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=8ed3f848-a1d2-e1ce-a3b0-d4e6d2d12d9d@huawei.com \
    --to=houtao1@huawei.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

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