From: Richard Weinberger <richard@nod.at>
To: linux-mtd@lists.infradead.org
Cc: Richard Weinberger <richard@nod.at>, stefan@agner.ch
Subject: [PATCH 0/3] UBIFS: xattr deletion rework
Date: Fri, 5 Apr 2019 00:34:35 +0200 [thread overview]
Message-ID: <20190404223438.29408-1-richard@nod.at> (raw)
UBIFS handles xattrs in most cases just like files.
An inode can have child entries, which are inodes for xattrs.
If an inode with xattrs is unlinked, only the hosting inode is
referenced in the journal and the orphan list. Upon recovery
all xattrs will be looked up from the TNC and also deleted.
This works in theory, but not in practice. The problem is that
in many places UBIFS internally assumes that a directory inode
can only be deleted if the directory is empty. Since xattr
hosting inodes are treated like directories but you can unlink
such an inode before all xattrs are gone, this assumption is violated.
Therefore it can happen that the garbage collector consumes a LEB
which hosts the information about xattr inodes because the host inode
itself got unlinked. Upon recovery UBIFS is no longer able to
locate these inodes and the free space accounting can get confused.
This can lead to all kind of filesystem corruptions.
The solution is to log every inode in the journal upon unlink.
This approach has one downside, we need to lower the amount of allowed
xattrs per inode.
With this changes applied UBIFS still supports dozens of xattrs per
inode.
Hunting down this issue down was anything but easy.
I'd like to thank Toradex AG for supporing this bug hunt.
Special thanks to Stefan Agner for his constant support and testing my
debug patches over and over.
Richard Weinberger (3):
ubifs: journal: Handle xattrs like files
ubifs: orphan: Handle xattrs like files
ubifs: Limit number of xattrs per inode
fs/ubifs/dir.c | 15 +++-
fs/ubifs/journal.c | 72 ++++++++++++++++---
fs/ubifs/misc.h | 8 +++
fs/ubifs/orphan.c | 208 ++++++++++++++++++++++++++++++++++++-----------------
fs/ubifs/super.c | 2 +
fs/ubifs/ubifs.h | 4 ++
fs/ubifs/xattr.c | 71 ++++++++++++++++--
7 files changed, 294 insertions(+), 86 deletions(-)
--
2.16.4
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next reply other threads:[~2019-04-04 22:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-04 22:34 Richard Weinberger [this message]
2019-04-04 22:34 ` [PATCH 1/3] ubifs: journal: Handle xattrs like files Richard Weinberger
2019-04-04 22:34 ` [PATCH 2/3] ubifs: orphan: " Richard Weinberger
2019-04-04 22:34 ` [PATCH 3/3] ubifs: Limit number of xattrs per inode Richard Weinberger
2019-04-25 14:51 ` [PATCH 0/3] UBIFS: xattr deletion rework Stefan Agner
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=20190404223438.29408-1-richard@nod.at \
--to=richard@nod.at \
--cc=linux-mtd@lists.infradead.org \
--cc=stefan@agner.ch \
/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.