linux-stable.git/fs/xfs, branch linux-3.14.y

xfs: fix up backport error in fs/xfs/xfs_inode.c

2016-06-24T17:15:29+00:00

Commit c66edeaf79bb6f0ca688ffec9ca50a61b7569984, which was a backport of
commit b1438f477934f5a4d5a44df26f3079a7575d5946 upstream, needed to have
the error value be positive, not negative, in order to work properly.

Reported-by: "Thomas D." 
Reported-by: Brad Spender 
Cc: Dave Chinner 
Cc: Willy Tarreau 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

xfs: skip stale inodes in xfs_iflush_cluster

2016-06-08T00:21:59+00:00

commit 7d3aa7fe970791f1a674b14572a411accf2f4d4e upstream.

We don't write back stale inodes so we should skip them in
xfs_iflush_cluster, too.

Signed-off-by: Dave Chinner 
Reviewed-by: Brian Foster 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman

xfs: fix inode validity check in xfs_iflush_cluster

2016-06-08T00:21:59+00:00

commit 51b07f30a71c27405259a0248206ed4e22adbee2 upstream.

Some careless idiot(*) wrote crap code in commit 1a3e8f3 ("xfs:
convert inode cache lookups to use RCU locking") back in late 2010,
and so xfs_iflush_cluster checks the wrong inode for whether it is
still valid under RCU protection. Fix it to lock and check the
correct inode.

(*) Careless-idiot: Dave Chinner 

Discovered-by: Brain Foster 
Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman

xfs: xfs_iflush_cluster fails to abort on error

2016-06-08T00:21:59+00:00

commit b1438f477934f5a4d5a44df26f3079a7575d5946 upstream.

When a failure due to an inode buffer occurs, the error handling
fails to abort the inode writeback correctly. This can result in the
inode being reclaimed whilst still in the AIL, leading to
use-after-free situations as well as filesystems that cannot be
unmounted as the inode log items left in the AIL never get removed.

Fix this by ensuring fatal errors from xfs_imap_to_bp() result in
the inode flush being aborted correctly.

Reported-by: Shyam Kaushik 
Diagnosed-by: Shyam Kaushik 
Tested-by: Shyam Kaushik 
Signed-off-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman

xfs: fix two memory leaks in xfs_attr_list.c error paths

2016-04-12T16:12:46+00:00

commit 2e83b79b2d6c78bf1b4aa227938a214dcbddc83f upstream.

This plugs 2 trivial leaks in xfs_attr_shortform_list and
xfs_attr3_leaf_list_int.

Signed-off-by: Mateusz Guzik 
Reviewed-by: Eric Sandeen 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman

xfs: fix remote symlinks on V5/CRC filesystems

2015-08-03T16:29:56+00:00

commit 2ac56d3d4bd625450a54d4c3f9292d58f6b88232 upstream.

If we create a CRC filesystem, mount it, and create a symlink with
a path long enough that it can't live in the inode, we get a very
strange result upon remount:

# ls -l mnt
total 4
lrwxrwxrwx. 1 root root 929 Jun 15 16:58 link -> XSLM

XSLM is the V5 symlink block header magic (which happens to be
followed by a NUL, so the string looks terminated).

xfs_readlink_bmap() advanced cur_chunk by the size of the header
for CRC filesystems, but never actually used that pointer; it
kept reading from bp->b_addr, which is the start of the block,
rather than the start of the symlink data after the header.

Looks like this problem goes back to v3.10.

Fixing this gets us reading the proper link target, again.

Signed-off-by: Eric Sandeen 
Reviewed-by: Dave Chinner 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman

xfs: Fix quota type in quota structures when reusing quota file

2015-03-06T22:43:31+00:00

commit dfcc70a8c868fe03276fa59864149708fb41930b upstream.

For filesystems without separate project quota inode field in the
superblock we just reuse project quota file for group quotas (and vice
versa) if project quota file is allocated and we need group quota file.
When we reuse the file, quota structures on disk suddenly have wrong
type stored in d_flags though. Nobody really cares about this (although
structure type reported to userspace was wrong as well) except
that after commit 14bf61ffe6ac (quota: Switch ->get_dqblk() and
->set_dqblk() to use bytes as space units) assertion in
xfs_qm_scall_getquota() started to trigger on xfs/106 test (apparently I
was testing without XFS_DEBUG so I didn't notice when submitting the
above commit).

Fix the problem by properly resetting ddq->d_flags when running quotacheck
for a quota file.

Reported-by: Al Viro 
Signed-off-by: Jan Kara 
Reviewed-by: Dave Chinner 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman

xfs: set superblock buffer type correctly

2015-03-06T22:43:23+00:00

commit 3443a3bca54588f43286b725d8648d33a38c86f1 upstream.

When the superblock is modified in a transaction, the commonly
modified fields are not actually copied to the superblock buffer to
avoid the buffer lock becoming a serialisation point. However, there
are some other operations that modify the superblock fields within
the transaction that don't directly log to the superblock but rely
on the changes to be applied during the transaction commit (to
minimise the buffer lock hold time).

When we do this, we fail to mark the buffer log item as being a
superblock buffer and that can lead to the buffer not being marked
with the corect type in the log and hence causing recovery issues.
Fix it by setting the type correctly, similar to xfs_mod_sb()...

Tested-by: Jan Kara 
Signed-off-by: Dave Chinner 
Reviewed-by: Brian Foster 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman

xfs: inode unlink does not set AGI buffer type

2015-03-06T22:43:23+00:00

commit f19b872b086711bb4b22c3a0f52f16aa920bcc61 upstream.

This leads to log recovery throwing errors like:

XFS (md0): Mounting V5 Filesystem
XFS (md0): Starting recovery (logdev: internal)
XFS (md0): Unknown buffer type 0!
XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1
ffff8800ffc53800: 58 41 47 49 .....

Which is the AGI buffer magic number.

Ensure that we set the type appropriately in both unlink list
addition and removal.

Tested-by: Jan Kara 
Signed-off-by: Dave Chinner 
Reviewed-by: Brian Foster 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman

xfs: ensure buffer types are set correctly

2015-03-06T22:43:22+00:00

commit 0d612fb570b71ea2e49554a770cff4c489018b2c upstream.

Jan Kara reported that log recovery was finding buffers with invalid
types in them. This should not happen, and indicates a bug in the
logging of buffers. To catch this, add asserts to the buffer
formatting code to ensure that the buffer type is in range when the
transaction is committed.

We don't set a type on buffers being marked stale - they are not
going to get replayed, the format item exists only for recovery to
be able to prevent replay of the buffer, so the type does not
matter. Hence that needs special casing here.

Reported-by: Jan Kara 
Tested-by: Jan Kara 
Signed-off-by: Dave Chinner 
Reviewed-by: Brian Foster 
Signed-off-by: Dave Chinner 
Signed-off-by: Greg Kroah-Hartman