linux-stable.git/fs, branch v3.16.74

xfs: clear sb->s_fs_info on mount failure

2019-09-23T20:12:08+00:00

commit c9fbd7bbc23dbdd73364be4d045e5d3612cf6e82 upstream.

We recently had an oops reported on a 4.14 kernel in
xfs_reclaim_inodes_count() where sb->s_fs_info pointed to garbage
and so the m_perag_tree lookup walked into lala land.

Essentially, the machine was under memory pressure when the mount
was being run, xfs_fs_fill_super() failed after allocating the
xfs_mount and attaching it to sb->s_fs_info. It then cleaned up and
freed the xfs_mount, but the sb->s_fs_info field still pointed to
the freed memory. Hence when the superblock shrinker then ran
it fell off the bad pointer.

With the superblock shrinker problem fixed at teh VFS level, this
stale s_fs_info pointer is still a problem - we use it
unconditionally in ->put_super when the superblock is being torn
down, and hence we can still trip over it after a ->fill_super
call failure. Hence we need to clear s_fs_info if
xfs-fs_fill_super() fails, and we need to check if it's valid in
the places it can potentially be dereferenced after a ->fill_super
failure.

Signed-Off-By: Dave Chinner 
Reviewed-by: Darrick J. Wong 
Signed-off-by: Darrick J. Wong 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

GFS2: don't set rgrp gl_object until it's inserted into rgrp tree

2019-09-23T20:12:08+00:00

commit 36e4ad0316c017d5b271378ed9a1c9a4b77fab5f upstream.

Before this patch, function read_rindex_entry would set a rgrp
glock's gl_object pointer to itself before inserting the rgrp into
the rgrp rbtree. The problem is: if another process was also reading
the rgrp in, and had already inserted its newly created rgrp, then
the second call to read_rindex_entry would overwrite that value,
then return a bad return code to the caller. Later, other functions
would reference the now-freed rgrp memory by way of gl_object.
In some cases, that could result in gfs2_rgrp_brelse being called
twice for the same rgrp: once for the failed attempt and once for
the "real" rgrp release. Eventually the kernel would panic.
There are also a number of other things that could go wrong when
a kernel module is accessing freed storage. For example, this could
result in rgrp corruption because the fake rgrp would point to a
fake bitmap in memory too, causing gfs2_inplace_reserve to search
some random memory for free blocks, and find some, since we were
never setting rgd->rd_bits to NULL before freeing it.

This patch fixes the problem by not setting gl_object until we
have successfully inserted the rgrp into the rbtree. Also, it sets
rd_bits to NULL as it frees them, which will ensure any accidental
access to the wrong rgrp will result in a kernel panic rather than
file system corruption, which is preferred.

Signed-off-by: Bob Peterson 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

GFS2: Fix rgrp end rounding problem for bsize < page size

2019-09-23T20:12:07+00:00

commit 31dddd9eb9ebae9a2a9b502750e9e481d752180a upstream.

This patch fixes a bug introduced by commit 7005c3e. That patch
tries to map a vm range for resource groups, but the calculation
breaks down when the block size is less than the page size.

Signed-off-by: Bob Peterson 
Signed-off-by: Ben Hutchings

ocfs2: fix ocfs2 read inode data panic in ocfs2_iget

2019-09-23T20:12:06+00:00

commit e091eab028f9253eac5c04f9141bbc9d170acab3 upstream.

In some cases, ocfs2_iget() reads the data of inode, which has been
deleted for some reason.  That will make the system panic.  So We should
judge whether this inode has been deleted, and tell the caller that the
inode is a bad inode.

For example, the ocfs2 is used as the backed of nfs, and the client is
nfsv3.  This issue can be reproduced by the following steps.

on the nfs server side,
..../patha/pathb

Step 1: The process A was scheduled before calling the function fh_verify.

Step 2: The process B is removing the 'pathb', and just completed the call
to function dput.  Then the dentry of 'pathb' has been deleted from the
dcache, and all ancestors have been deleted also.  The relationship of
dentry and inode was deleted through the function hlist_del_init.  The
following is the call stack.
dentry_iput->hlist_del_init(&dentry->d_u.d_alias)

At this time, the inode is still in the dcache.

Step 3: The process A call the function ocfs2_get_dentry, which get the
inode from dcache.  Then the refcount of inode is 1.  The following is the
call stack.
nfsd3_proc_getacl->fh_verify->exportfs_decode_fh->fh_to_dentry(ocfs2_get_dentry)

Step 4: Dirty pages are flushed by bdi threads.  So the inode of 'patha'
is evicted, and this directory was deleted.  But the inode of 'pathb'
can't be evicted, because the refcount of the inode was 1.

Step 5: The process A keep running, and call the function
reconnect_path(in exportfs_decode_fh), which call function
ocfs2_get_parent of ocfs2.  Get the block number of parent
directory(patha) by the name of ...  Then read the data from disk by the
block number.  But this inode has been deleted, so the system panic.

Process A                                             Process B
1. in nfsd3_proc_getacl                   |
2.                                        |        dput
3. fh_to_dentry(ocfs2_get_dentry)         |
4. bdi flush dirty cache                  |
5. ocfs2_iget                             |

[283465.542049] OCFS2: ERROR (device sdp): ocfs2_validate_inode_block:
Invalid dinode #580640: OCFS2_VALID_FL not set

[283465.545490] Kernel panic - not syncing: OCFS2: (device sdp): panic forced
after error

[283465.546889] CPU: 5 PID: 12416 Comm: nfsd Tainted: G        W
4.1.12-124.18.6.el6uek.bug28762940v3.x86_64 #2
[283465.548382] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 09/21/2015
[283465.549657]  0000000000000000 ffff8800a56fb7b8 ffffffff816e839c
ffffffffa0514758
[283465.550392]  000000000008dc20 ffff8800a56fb838 ffffffff816e62d3
0000000000000008
[283465.551056]  ffff880000000010 ffff8800a56fb848 ffff8800a56fb7e8
ffff88005df9f000
[283465.551710] Call Trace:
[283465.552516]  [] dump_stack+0x63/0x81
[283465.553291]  [] panic+0xcb/0x21b
[283465.554037]  [] ocfs2_handle_error+0xf0/0xf0 [ocfs2]
[283465.554882]  [] __ocfs2_error+0x67/0x70 [ocfs2]
[283465.555768]  [] ocfs2_validate_inode_block+0x229/0x230
[ocfs2]
[283465.556683]  [] ocfs2_read_blocks+0x46c/0x7b0 [ocfs2]
[283465.557408]  [] ? ocfs2_inode_cache_io_unlock+0x20/0x20
[ocfs2]
[283465.557973]  [] ocfs2_read_inode_block_full+0x3b/0x60
[ocfs2]
[283465.558525]  [] ocfs2_iget+0x4aa/0x880 [ocfs2]
[283465.559082]  [] ocfs2_get_parent+0x9e/0x220 [ocfs2]
[283465.559622]  [] reconnect_path+0xb5/0x300
[283465.560156]  [] exportfs_decode_fh+0xf6/0x2b0
[283465.560708]  [] ? nfsd_proc_getattr+0xa0/0xa0 [nfsd]
[283465.561262]  [] ? prepare_creds+0x26/0x110
[283465.561932]  [] fh_verify+0x350/0x660 [nfsd]
[283465.562862]  [] ? nfsd_cache_lookup+0x44/0x630 [nfsd]
[283465.563697]  [] nfsd3_proc_getattr+0x69/0xf0 [nfsd]
[283465.564510]  [] nfsd_dispatch+0xe0/0x290 [nfsd]
[283465.565358]  [] ? svc_tcp_adjust_wspace+0x12/0x30
[sunrpc]
[283465.566272]  [] svc_process_common+0x412/0x6a0 [sunrpc]
[283465.567155]  [] svc_process+0x123/0x210 [sunrpc]
[283465.568020]  [] nfsd+0xff/0x170 [nfsd]
[283465.568962]  [] ? nfsd_destroy+0x80/0x80 [nfsd]
[283465.570112]  [] kthread+0xcb/0xf0
[283465.571099]  [] ? kthread_create_on_node+0x180/0x180
[283465.572114]  [] ret_from_fork+0x58/0x90
[283465.573156]  [] ? kthread_create_on_node+0x180/0x180

Link: http://lkml.kernel.org/r/1554185919-3010-1-git-send-email-sunny.s.zhang@oracle.com
Signed-off-by: Shuning Zhang 
Reviewed-by: Joseph Qi 
Cc: Mark Fasheh 
Cc: Joel Becker 
Cc: Junxiao Bi 
Cc: Changwei Ge 
Cc: piaojun 
Cc: "Gang He" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

ext4: fix data corruption caused by overlapping unaligned and aligned IO

2019-09-23T20:12:04+00:00

commit 57a0da28ced8707cb9f79f071a016b9d005caf5a upstream.

Unaligned AIO must be serialized because the zeroing of partial blocks
of unaligned AIO can result in data corruption in case it's overlapping
another in flight IO.

Currently we wait for all unwritten extents before we submit unaligned
AIO which protects data in case of unaligned AIO is following overlapping
IO. However if a unaligned AIO is followed by overlapping aligned AIO we
can still end up corrupting data.

To fix this, we must make sure that the unaligned AIO is the only IO in
flight by waiting for unwritten extents conversion not just before the
IO submission, but right after it as well.

This problem can be reproduced by xfstest generic/538

Signed-off-by: Lukas Czerner 
Signed-off-by: Theodore Ts'o 
[bwh: Backported to 3.16:
 - Test aio_mutex instead of unaligned_aio
 - Adjust context]
Signed-off-by: Ben Hutchings

NFS4: Fix v4.0 client state corruption when mount

2019-09-23T20:12:03+00:00

commit f02f3755dbd14fb935d24b14650fff9ba92243b8 upstream.

stat command with soft mount never return after server is stopped.

When alloc a new client, the state of the client will be set to
NFS4CLNT_LEASE_EXPIRED.

When the server is stopped, the state manager will work, and accord
the state to recover. But the state is NFS4CLNT_LEASE_EXPIRED, it
will drain the slot table and lead other task to wait queue, until
the client recovered. Then the stat command is hung.

When discover server trunking, the client will renew the lease,
but check the client state, it lead the client state corruption.

So, we need to call state manager to recover it when detect server
ip trunking.

Signed-off-by: ZhangXiaoxu 
Signed-off-by: Anna Schumaker 
Signed-off-by: Ben Hutchings

cifs: fix strcat buffer overflow and reduce raciness in smb21_set_oplock_level()

2019-09-23T20:12:00+00:00

commit 6a54b2e002c9d00b398d35724c79f9fe0d9b38fb upstream.

Change strcat to strncpy in the "None" case to fix a buffer overflow
when cinode->oplock is reset to 0 by another thread accessing the same
cinode. It is never valid to append "None" to any other message.

Consolidate multiple writes to cinode->oplock to reduce raciness.

Signed-off-by: Christoph Probst 
Reviewed-by: Pavel Shilovsky 
Signed-off-by: Steve French 
Signed-off-by: Ben Hutchings

ceph: flush dirty inodes before proceeding with remount

2019-09-23T20:12:00+00:00

commit 00abf69dd24f4444d185982379c5cc3bb7b6d1fc upstream.

xfstest generic/452 was triggering a "Busy inodes after umount" warning.
ceph was allowing the mount to go read-only without first flushing out
dirty inodes in the cache. Ensure we sync out the filesystem before
allowing a remount to proceed.

Link: http://tracker.ceph.com/issues/39571
Signed-off-by: Jeff Layton 
Reviewed-by: "Yan, Zheng" 
Signed-off-by: Ilya Dryomov 
Signed-off-by: Ben Hutchings

ext4: actually request zeroing of inode table after grow

2019-09-23T20:11:53+00:00

commit 310a997fd74de778b9a4848a64be9cda9f18764a upstream.

It is never possible, that number of block groups decreases,
since only online grow is supported.

But after a growing occured, we have to zero inode tables
for just created new block groups.

Fixes: 19c5246d2516 ("ext4: add new online resize interface")
Signed-off-by: Kirill Tkhai 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Jan Kara 
Signed-off-by: Ben Hutchings

fuse: fallocate: fix return with locked inode

2019-09-23T20:11:48+00:00

commit 35d6fcbb7c3e296a52136347346a698a35af3fda upstream.

Do the proper cleanup in case the size check fails.

Tested with xfstests:generic/228

Reported-by: kbuild test robot 
Reported-by: Dan Carpenter 
Fixes: 0cbade024ba5 ("fuse: honor RLIMIT_FSIZE in fuse_file_fallocate")
Cc: Liu Bo 
Signed-off-by: Miklos Szeredi 
Signed-off-by: Ben Hutchings