linux-stable.git/fs/ext4, branch v4.4.27

ext4: release bh in make_indexed_dir

2016-10-22T10:26:56+00:00

commit e81d44778d1d57bbaef9e24c4eac7c8a7a401d40 upstream.

The commit 6050d47adcad: "ext4: bail out from make_indexed_dir() on
first error" could end up leaking bh2 in the error path.

[ Also avoid renaming bh2 to bh, which just confuses things --tytso ]

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

ext4: allow DAX writeback for hole punch

2016-10-22T10:26:56+00:00

commit cca32b7eeb4ea24fa6596650e06279ad9130af98 upstream.

Currently when doing a DAX hole punch with ext4 we fail to do a writeback.
This is because the logic around filemap_write_and_wait_range() in
ext4_punch_hole() only looks for dirty page cache pages in the radix tree,
not for dirty DAX exceptional entries.

Signed-off-by: Ross Zwisler 
Reviewed-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

ext4: fix memory leak in ext4_insert_range()

2016-10-22T10:26:56+00:00

commit edf15aa180d7b98fe16bd3eda42f9dd0e60dee20 upstream.

Running xfstests generic/013 with kmemleak gives the following:

unreferenced object 0xffff8801d3d27de0 (size 96):
  comm "fsstress", pid 4941, jiffies 4294860168 (age 53.485s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] kmemleak_alloc+0x23/0x40
    [] __kmalloc+0xf5/0x1d0
    [] ext4_find_extent+0x1ec/0x2f0
    [] ext4_insert_range+0x34c/0x4a0
    [] ext4_fallocate+0x4e2/0x8b0
    [] vfs_fallocate+0x134/0x210
    [] SyS_fallocate+0x3f/0x60
    [] entry_SYSCALL_64_fastpath+0x13/0x8f
    [] 0xffffffffffffffff

Problem seems mitigated by dropping refs and freeing path
when there's no path[depth].p_ext

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

ext4: reinforce check of i_dtime when clearing high fields of uid and gid

2016-10-22T10:26:56+00:00

commit 93e3b4e6631d2a74a8cf7429138096862ff9f452 upstream.

Now, ext4_do_update_inode() clears high 16-bit fields of uid/gid
of deleted and evicted inode to fix up interoperability with old
kernels. However, it checks only i_dtime of an inode to determine
whether the inode was deleted and evicted, and this is very risky,
because i_dtime can be used for the pointer maintaining orphan inode
list, too. We need to further check whether the i_dtime is being
used for the orphan inode list even if the i_dtime is not NULL.

We found that high 16-bit fields of uid/gid of inode are unintentionally
and permanently cleared when the inode truncation is just triggered,
but not finished, and the inode metadata, whose high uid/gid bits are
cleared, is written on disk, and the sudden power-off follows that
in order.

Signed-off-by: Daeho Jeong 
Signed-off-by: Hobin Woo 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

ext4: enforce online defrag restriction for encrypted files

2016-10-22T10:26:56+00:00

commit 14fbd4aa613bd5110556c281799ce36dc6f3ba97 upstream.

Online defragging of encrypted files is not currently implemented.
However, the move extent ioctl can still return successfully when
called.  For example, this occurs when xfstest ext4/020 is run on an
encrypted file system, resulting in a corrupted test file and a
corresponding test failure.

Until the proper functionality is implemented, fail the move extent
ioctl if either the original or donor file is encrypted.

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

fscrypto: require write access to mount to set encryption policy

2016-09-24T08:07:35+00:00

commit ba63f23d69a3a10e7e527a02702023da68ef8a6d upstream.

Since setting an encryption policy requires writing metadata to the
filesystem, it should be guarded by mnt_want_write/mnt_drop_write.
Otherwise, a user could cause a write to a frozen or readonly
filesystem.  This was handled correctly by f2fs but not by ext4.  Make
fscrypt_process_policy() handle it rather than relying on the filesystem
to get it right.

Signed-off-by: Eric Biggers 
Cc: stable@vger.kernel.org # 4.1+; check fs/{ext4,f2fs}
Signed-off-by: Theodore Ts'o 
Acked-by: Jaegeuk Kim 
Signed-off-by: Greg Kroah-Hartman

fscrypto: add authorization check for setting encryption policy

2016-09-24T08:07:34+00:00

commit 163ae1c6ad6299b19e22b4a35d5ab24a89791a98 upstream.

On an ext4 or f2fs filesystem with file encryption supported, a user
could set an encryption policy on any empty directory(*) to which they
had readonly access.  This is obviously problematic, since such a
directory might be owned by another user and the new encryption policy
would prevent that other user from creating files in their own directory
(for example).

Fix this by requiring inode_owner_or_capable() permission to set an
encryption policy.  This means that either the caller must own the file,
or the caller must have the capability CAP_FOWNER.

(*) Or also on any regular file, for f2fs v4.6 and later and ext4
    v4.8-rc1 and later; a separate bug fix is coming for that.

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

ext4: use __GFP_NOFAIL in ext4_free_blocks()

2016-09-24T08:07:34+00:00

commit adb7ef600cc9d9d15ecc934cc26af5c1379777df upstream.

This might be unexpected but pages allocated for sbi->s_buddy_cache are
charged to current memory cgroup. So, GFP_NOFS allocation could fail if
current task has been killed by OOM or if current memory cgroup has no
free memory left. Block allocator cannot handle such failures here yet.

Signed-off-by: Konstantin Khlebnikov 
Signed-off-by: Theodore Ts'o 
Cc: Jan Kara 
Signed-off-by: Greg Kroah-Hartman

ext4: avoid modifying checksum fields directly during checksum verification

2016-09-15T06:27:51+00:00

commit b47820edd1634dc1208f9212b7ecfb4230610a23 upstream.

We temporally change checksum fields in buffers of some types of
metadata into '0' for verifying the checksum values. By doing this
without locking the buffer, some metadata's checksums, which are
being committed or written back to the storage, could be damaged.
In our test, several metadata blocks were found with damaged metadata
checksum value during recovery process. When we only verify the
checksum value, we have to avoid modifying checksum fields directly.

Signed-off-by: Daeho Jeong 
Signed-off-by: Youngjin Gil 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Darrick J. Wong 
Cc: Török Edwin 
Signed-off-by: Greg Kroah-Hartman

ext4: avoid deadlock when expanding inode size

2016-09-15T06:27:50+00:00

commit 2e81a4eeedcaa66e35f58b81e0755b87057ce392 upstream.

When we need to move xattrs into external xattr block, we call
ext4_xattr_block_set() from ext4_expand_extra_isize_ea(). That may end
up calling ext4_mark_inode_dirty() again which will recurse back into
the inode expansion code leading to deadlocks.

Protect from recursion using EXT4_STATE_NO_EXPAND inode flag and move
its management into ext4_expand_extra_isize_ea() since its manipulation
is safe there (due to xattr_sem) from possible races with
ext4_xattr_set_handle() which plays with it as well.

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