linux-stable.git/fs, branch v4.5.2

Btrfs: fix file/data loss caused by fsync after rename and new inode

2016-04-20T06:45:25+00:00

commit 56f23fdbb600e6087db7b009775b95ce07cc3195 upstream.

If we rename an inode A (be it a file or a directory), create a new
inode B with the old name of inode A and under the same parent directory,
fsync inode B and then power fail, at log tree replay time we end up
removing inode A completely. If inode A is a directory then all its files
are gone too.

Example scenarios where this happens:
This is reproducible with the following steps, taken from a couple of
test cases written for fstests which are going to be submitted upstream
soon:

   # Scenario 1

   mkfs.btrfs -f /dev/sdc
   mount /dev/sdc /mnt
   mkdir -p /mnt/a/x
   echo "hello" > /mnt/a/x/foo
   echo "world" > /mnt/a/x/bar
   sync
   mv /mnt/a/x /mnt/a/y
   mkdir /mnt/a/x
   xfs_io -c fsync /mnt/a/x
   

   The next time the fs is mounted, log tree replay happens and
   the directory "y" does not exist nor do the files "foo" and
   "bar" exist anywhere (neither in "y" nor in "x", nor the root
   nor anywhere).

   # Scenario 2

   mkfs.btrfs -f /dev/sdc
   mount /dev/sdc /mnt
   mkdir /mnt/a
   echo "hello" > /mnt/a/foo
   sync
   mv /mnt/a/foo /mnt/a/bar
   echo "world" > /mnt/a/foo
   xfs_io -c fsync /mnt/a/foo
   

   The next time the fs is mounted, log tree replay happens and the
   file "bar" does not exists anymore. A file with the name "foo"
   exists and it matches the second file we created.

Another related problem that does not involve file/data loss is when a
new inode is created with the name of a deleted snapshot and we fsync it:

   mkfs.btrfs -f /dev/sdc
   mount /dev/sdc /mnt
   mkdir /mnt/testdir
   btrfs subvolume snapshot /mnt /mnt/testdir/snap
   btrfs subvolume delete /mnt/testdir/snap
   rmdir /mnt/testdir
   mkdir /mnt/testdir
   xfs_io -c fsync /mnt/testdir # or fsync some file inside /mnt/testdir
   

   The next time the fs is mounted the log replay procedure fails because
   it attempts to delete the snapshot entry (which has dir item key type
   of BTRFS_ROOT_ITEM_KEY) as if it were a regular (non-root) entry,
   resulting in the following error that causes mount to fail:

   [52174.510532] BTRFS info (device dm-0): failed to delete reference to snap, inode 257 parent 257
   [52174.512570] ------------[ cut here ]------------
   [52174.513278] WARNING: CPU: 12 PID: 28024 at fs/btrfs/inode.c:3986 __btrfs_unlink_inode+0x178/0x351 [btrfs]()
   [52174.514681] BTRFS: Transaction aborted (error -2)
   [52174.515630] Modules linked in: btrfs dm_flakey dm_mod overlay crc32c_generic ppdev xor raid6_pq acpi_cpufreq parport_pc tpm_tis sg parport tpm evdev i2c_piix4 proc
   [52174.521568] CPU: 12 PID: 28024 Comm: mount Tainted: G        W       4.5.0-rc6-btrfs-next-27+ #1
   [52174.522805] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
   [52174.524053]  0000000000000000 ffff8801df2a7710 ffffffff81264e93 ffff8801df2a7758
   [52174.524053]  0000000000000009 ffff8801df2a7748 ffffffff81051618 ffffffffa03591cd
   [52174.524053]  00000000fffffffe ffff88015e6e5000 ffff88016dbc3c88 ffff88016dbc3c88
   [52174.524053] Call Trace:
   [52174.524053]  [] dump_stack+0x67/0x90
   [52174.524053]  [] warn_slowpath_common+0x99/0xb2
   [52174.524053]  [] ? __btrfs_unlink_inode+0x178/0x351 [btrfs]
   [52174.524053]  [] warn_slowpath_fmt+0x48/0x50
   [52174.524053]  [] __btrfs_unlink_inode+0x178/0x351 [btrfs]
   [52174.524053]  [] ? iput+0xb0/0x284
   [52174.524053]  [] btrfs_unlink_inode+0x1c/0x3d [btrfs]
   [52174.524053]  [] check_item_in_log+0x1fe/0x29b [btrfs]
   [52174.524053]  [] replay_dir_deletes+0x167/0x1cf [btrfs]
   [52174.524053]  [] fixup_inode_link_count+0x289/0x2aa [btrfs]
   [52174.524053]  [] fixup_inode_link_counts+0xcb/0x105 [btrfs]
   [52174.524053]  [] btrfs_recover_log_trees+0x258/0x32c [btrfs]
   [52174.524053]  [] ? replay_one_extent+0x511/0x511 [btrfs]
   [52174.524053]  [] open_ctree+0x1dd4/0x21b9 [btrfs]
   [52174.524053]  [] btrfs_mount+0x97e/0xaed [btrfs]
   [52174.524053]  [] ? trace_hardirqs_on+0xd/0xf
   [52174.524053]  [] mount_fs+0x67/0x131
   [52174.524053]  [] vfs_kern_mount+0x6c/0xde
   [52174.524053]  [] btrfs_mount+0x1ac/0xaed [btrfs]
   [52174.524053]  [] ? trace_hardirqs_on+0xd/0xf
   [52174.524053]  [] ? lockdep_init_map+0xb9/0x1b3
   [52174.524053]  [] mount_fs+0x67/0x131
   [52174.524053]  [] vfs_kern_mount+0x6c/0xde
   [52174.524053]  [] do_mount+0x8a6/0x9e8
   [52174.524053]  [] ? strndup_user+0x3f/0x59
   [52174.524053]  [] SyS_mount+0x77/0x9f
   [52174.524053]  [] entry_SYSCALL_64_fastpath+0x12/0x6b
   [52174.561288] ---[ end trace 6b53049efb1a3ea6 ]---

Fix this by forcing a transaction commit when such cases happen.
This means we check in the commit root of the subvolume tree if there
was any other inode with the same reference when the inode we are
fsync'ing is a new inode (created in the current transaction).

Test cases for fstests, covering all the scenarios given above, were
submitted upstream for fstests:

  * fstests: generic test for fsync after renaming directory
    https://patchwork.kernel.org/patch/8694281/

  * fstests: generic test for fsync after renaming file
    https://patchwork.kernel.org/patch/8694301/

  * fstests: add btrfs test for fsync after snapshot deletion
    https://patchwork.kernel.org/patch/8670671/

Signed-off-by: Filipe Manana 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

ext4: ignore quota mount options if the quota feature is enabled

2016-04-20T06:45:25+00:00

commit c325a67c72903e1cc30e990a15ce745bda0dbfde upstream.

Previously, ext4 would fail the mount if the file system had the quota
feature enabled and quota mount options (used for the older quota
setups) were present.  This broke xfstests, since xfs silently ignores
the usrquote and grpquota mount options if they are specified.  This
commit changes things so that we are consistent with xfs; having the
mount options specified is harmless, so no sense break users by
forbidding them.

Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

ext4: add lockdep annotations for i_data_sem

2016-04-20T06:45:25+00:00

commit daf647d2dd58cec59570d7698a45b98e580f2076 upstream.

With the internal Quota feature, mke2fs creates empty quota inodes and
quota usage tracking is enabled as soon as the file system is mounted.
Since quotacheck is no longer preallocating all of the blocks in the
quota inode that are likely needed to be written to, we are now seeing
a lockdep false positive caused by needing to allocate a quota block
from inside ext4_map_blocks(), while holding i_data_sem for a data
inode.  This results in this complaint:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&ei->i_data_sem);
                                lock(&s->s_dquot.dqio_mutex);
                                lock(&ei->i_data_sem);
   lock(&s->s_dquot.dqio_mutex);

Google-Bug-Id: 27907753

Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

btrfs: fix crash/invalid memory access on fsync when using overlayfs

2016-04-20T06:45:25+00:00

commit de17e793b104d690e1d007dfc5cb6b4f649598ca upstream.

If the lower or upper directory of an overlayfs mount belong to a btrfs
file system and we fsync the file through the overlayfs' merged directory
we ended up accessing an inode that didn't belong to btrfs as if it were
a btrfs inode at btrfs_sync_file() resulting in a crash like the following:

[ 7782.588845] BUG: unable to handle kernel NULL pointer dereference at 0000000000000544
[ 7782.590624] IP: [] btrfs_sync_file+0x11b/0x3e9 [btrfs]
[ 7782.591931] PGD 4d954067 PUD 1e878067 PMD 0
[ 7782.592016] Oops: 0002 [#6] PREEMPT SMP DEBUG_PAGEALLOC
[ 7782.592016] Modules linked in: btrfs overlay ppdev crc32c_generic evdev xor raid6_pq psmouse pcspkr sg serio_raw acpi_cpufreq parport_pc parport tpm_tis i2c_piix4 tpm i2c_core processor button loop autofs4 ext4 crc16 mbcache jbd2 sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix virtio_pci libata virtio_ring virtio scsi_mod e1000 floppy [last unloaded: btrfs]
[ 7782.592016] CPU: 10 PID: 16437 Comm: xfs_io Tainted: G      D         4.5.0-rc6-btrfs-next-26+ #1
[ 7782.592016] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
[ 7782.592016] task: ffff88001b8d40c0 ti: ffff880137488000 task.ti: ffff880137488000
[ 7782.592016] RIP: 0010:[]  [] btrfs_sync_file+0x11b/0x3e9 [btrfs]
[ 7782.592016] RSP: 0018:ffff88013748be40  EFLAGS: 00010286
[ 7782.592016] RAX: 0000000080000000 RBX: ffff880133b30c88 RCX: 0000000000000001
[ 7782.592016] RDX: 0000000000000001 RSI: ffffffff8148fec0 RDI: 00000000ffffffff
[ 7782.592016] RBP: ffff88013748bec0 R08: 0000000000000001 R09: 0000000000000000
[ 7782.624248] R10: ffff88013748be40 R11: 0000000000000246 R12: 0000000000000000
[ 7782.624248] R13: 0000000000000000 R14: 00000000009305a0 R15: ffff880015e3be40
[ 7782.624248] FS:  00007fa83b9cb700(0000) GS:ffff88023ed40000(0000) knlGS:0000000000000000
[ 7782.624248] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7782.624248] CR2: 0000000000000544 CR3: 00000001fa652000 CR4: 00000000000006e0
[ 7782.624248] Stack:
[ 7782.624248]  ffffffff8108b5cc ffff88013748bec0 0000000000000246 ffff8800b005ded0
[ 7782.624248]  ffff880133b30d60 8000000000000000 7fffffffffffffff 0000000000000246
[ 7782.624248]  0000000000000246 ffffffff81074f9b ffffffff8104357c ffff880015e3be40
[ 7782.624248] Call Trace:
[ 7782.624248]  [] ? arch_local_irq_save+0x9/0xc
[ 7782.624248]  [] ? ___might_sleep+0xce/0x217
[ 7782.624248]  [] ? __do_page_fault+0x3c0/0x43a
[ 7782.624248]  [] vfs_fsync_range+0x8c/0x9e
[ 7782.624248]  [] vfs_fsync+0x1c/0x1e
[ 7782.624248]  [] do_fsync+0x31/0x4a
[ 7782.624248]  [] SyS_fsync+0x10/0x14
[ 7782.624248]  [] entry_SYSCALL_64_fastpath+0x12/0x6b
[ 7782.624248] Code: 85 c0 0f 85 e2 02 00 00 48 8b 45 b0 31 f6 4c 29 e8 48 ff c0 48 89 45 a8 48 8d 83 d8 00 00 00 48 89 c7 48 89 45 a0 e8 fc 43 18 e1  41 ff 84 24 44 05 00 00 48 8b 83 58 ff ff ff 48 c1 e8 07 83
[ 7782.624248] RIP  [] btrfs_sync_file+0x11b/0x3e9 [btrfs]
[ 7782.624248]  RSP 
[ 7782.624248] CR2: 0000000000000544
[ 7782.661994] ---[ end trace 721e14960eb939bc ]---

This started happening since commit 4bacc9c9234 (overlayfs: Make f_path
always point to the overlay and f_inode to the underlay) and even though
after this change we could still access the btrfs inode through
struct file->f_mapping->host or struct file->f_inode, we would end up
resulting in more similar issues later on at check_parent_dirs_for_sync()
because the dentry we got (from struct file->f_path.dentry) was from
overlayfs and not from btrfs, that is, we had no way of getting the dentry
that belonged to btrfs (we always got the dentry that belonged to
overlayfs).

The new patch from Miklos Szeredi, titled "vfs: add file_dentry()" and
recently submitted to linux-fsdevel, adds a file_dentry() API that allows
us to get the btrfs dentry from the input file and therefore being able
to fsync when the upper and lower directories belong to btrfs filesystems.

This issue has been reported several times by users in the mailing list
and bugzilla. A test case for xfstests is being submitted as well.

Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101951
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109791
Signed-off-by: Filipe Manana 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

ext4: use file_dentry()

2016-04-20T06:45:24+00:00

commit c0a37d48788475d0a2cf4fbfaa28559a9de612fc upstream.

EXT4 may be used as lower layer of overlayfs and accessing f_path.dentry
can lead to a crash.

Fix by replacing direct access of file->f_path.dentry with the
file_dentry() accessor, which will always return a native object.

Reported-by: Daniel Axtens 
Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
Fixes: ff978b09f973 ("ext4 crypto: move context consistency check to ext4_file_open()")
Signed-off-by: Miklos Szeredi 
Signed-off-by: Theodore Ts'o 
Cc: David Howells 
Cc: Al Viro 
Signed-off-by: Greg Kroah-Hartman

ext4: use dget_parent() in ext4_file_open()

2016-04-20T06:45:24+00:00

commit 9dd78d8c9a7bd4bc341f5864db32d4331b8eae4c upstream.

In f_op->open() lock on parent is not held, so there's no guarantee that
parent dentry won't go away at any time.

Even after this patch there's no guarantee that 'dir' will stay the parent
of 'inode', but at least it won't be freed while being used.

Fixes: ff978b09f973 ("ext4 crypto: move context consistency check to ext4_file_open()")
Signed-off-by: Miklos Szeredi 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

ext4 crypto: use dget_parent() in ext4_d_revalidate()

2016-04-20T06:45:24+00:00

commit 3d43bcfef5f0548845a425365011c499875491b0 upstream.

This avoids potential problems caused by a race where the inode gets
renamed out from its parent directory and the parent directory is
deleted while ext4_d_revalidate() is running.

Fixes: 28b4c263961c
Reported-by: Al Viro 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

nfs: use file_dentry()

2016-04-20T06:45:24+00:00

commit be62a1a8fd116f5cd9e53726601f970e16e17558 upstream.

NFS may be used as lower layer of overlayfs and accessing f_path.dentry can
lead to a crash.

Fix by replacing direct access of file->f_path.dentry with the
file_dentry() accessor, which will always return a native object.

Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
Signed-off-by: Miklos Szeredi 
Tested-by: Goldwyn Rodrigues 
Acked-by: Trond Myklebust 
Signed-off-by: Theodore Ts'o 
Cc: David Howells 
Cc: Al Viro 
Signed-off-by: Greg Kroah-Hartman

fs: add file_dentry()

2016-04-20T06:45:23+00:00

commit d101a125954eae1d397adda94ca6319485a50493 upstream.

This series fixes bugs in nfs and ext4 due to 4bacc9c9234c ("overlayfs:
Make f_path always point to the overlay and f_inode to the underlay").

Regular files opened on overlayfs will result in the file being opened on
the underlying filesystem, while f_path points to the overlayfs
mount/dentry.

This confuses filesystems which get the dentry from struct file and assume
it's theirs.

Add a new helper, file_dentry() [*], to get the filesystem's own dentry
from the file.  This checks file->f_path.dentry->d_flags against
DCACHE_OP_REAL, and returns file->f_path.dentry if DCACHE_OP_REAL is not
set (this is the common, non-overlayfs case).

In the uncommon case it will call into overlayfs's ->d_real() to get the
underlying dentry, matching file_inode(file).

The reason we need to check against the inode is that if the file is copied
up while being open, d_real() would return the upper dentry, while the open
file comes from the lower dentry.

[*] If possible, it's better simply to use file_inode() instead.

Signed-off-by: Miklos Szeredi 
Signed-off-by: Theodore Ts'o 
Tested-by: Goldwyn Rodrigues 
Reviewed-by: Trond Myklebust 
Cc: David Howells 
Cc: Al Viro 
Cc: Daniel Axtens 
Signed-off-by: Greg Kroah-Hartman

ocfs2/dlm: fix BUG in dlm_move_lockres_to_recovery_list

2016-04-12T14:33:48+00:00

commit be12b299a83fc807bbaccd2bcb8ec50cbb0cb55c upstream.

When master handles convert request, it queues ast first and then
returns status.  This may happen that the ast is sent before the request
status because the above two messages are sent by two threads.  And
right after the ast is sent, if master down, it may trigger BUG in
dlm_move_lockres_to_recovery_list in the requested node because ast
handler moves it to grant list without clear lock->convert_pending.  So
remove BUG_ON statement and check if the ast is processed in
dlmconvert_remote.

Signed-off-by: Joseph Qi 
Reported-by: Yiwen Jiang 
Cc: Junxiao Bi 
Cc: Mark Fasheh 
Cc: Joel Becker 
Cc: Tariq Saeed 
Cc: Junxiao Bi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman