diff options
author | Richard Weinberger <richard@nod.at> | 2017-05-17 01:20:27 +0300 |
---|---|---|
committer | Richard Weinberger <richard@nod.at> | 2017-07-14 23:49:04 +0300 |
commit | 272eda8298dc82eb411ece82bbb2c62911087b24 (patch) | |
tree | 5772eeddfafe6006785b13774dc221f92403b4b1 /fs/proc/consoles.c | |
parent | e996bfd4287eb7df2354764d47677af08f5867fa (diff) | |
download | linux-272eda8298dc82eb411ece82bbb2c62911087b24.tar.xz |
ubifs: Correctly evict xattr inodes
UBIFS handles extended attributes just like files, as consequence of
that, they also have inodes.
Therefore UBIFS does all the inode machinery also for xattrs. Since new
inodes have i_nlink of 1, a file or xattr inode will be evicted
if i_nlink goes down to 0 after an unlink. UBIFS assumes this model also
for xattrs, which is not correct.
One can create a file "foo" with xattr "user.test". By reading
"user.test" an inode will be created, and by deleting "user.test" it
will get evicted later. The assumption breaks if the file "foo", which
hosts the xattrs, will be removed. VFS nor UBIFS does not remove each
xattr via ubifs_xattr_remove(), it just removes the host inode from
the TNC and all underlying xattr nodes too and the inode will remain
in the cache and wastes memory.
To solve this problem, remove xattr inodes from the VFS inode cache in
ubifs_xattr_remove() to make sure that they get evicted.
Fixes: 1e51764a3c2ac05a ("UBIFS: add new flash file system")
Cc: <stable@vger.kernel.org>
Signed-off-by: Richard Weinberger <richard@nod.at>
Diffstat (limited to 'fs/proc/consoles.c')
0 files changed, 0 insertions, 0 deletions