linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Hou Tao <houtao1@huawei.com>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH 0/3] fixes for ubifs xattr operations
Date: Tue, 30 Jun 2020 15:15:01 +0200 (CEST)	[thread overview]
Message-ID: <25305185.75764.1593522901565.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <20200630130438.141649-1-houtao1@huawei.com>

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).

I'm a bit surprised that this can actually happen, I was under the impression
that vfs cares about this.

Thanks,
//richard

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

  parent reply	other threads:[~2020-06-30 13:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30 13:04 [PATCH 0/3] fixes for ubifs xattr operations 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 ` Richard Weinberger [this message]
2020-07-01  1:11   ` [PATCH 0/3] fixes for ubifs xattr operations Hou Tao
2020-10-23  7:19 ` Hou Tao
2020-10-31 21:10   ` Richard Weinberger
2020-11-03  2:04     ` Hou Tao
2020-11-03  8:19       ` Richard Weinberger
2021-02-24  2:49         ` 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=25305185.75764.1593522901565.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=houtao1@huawei.com \
    --cc=linux-mtd@lists.infradead.org \
    /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).