linux.git/fs, branch v4.4.69

CIFS: add misssing SFM mapping for doublequote

2017-05-20T12:27:01+00:00

commit 85435d7a15294f9f7ef23469e6aaf7c5dfcc54f0 upstream.

SFM is mapping doublequote to 0xF020

Without this patch creating files with doublequote fails to Windows/Mac

Signed-off-by: Bjoern Jacke 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

cifs: fix CIFS_IOC_GET_MNT_INFO oops

2017-05-20T12:27:01+00:00

commit d8a6e505d6bba2250852fbc1c1c86fe68aaf9af3 upstream.

An open directory may have a NULL private_data pointer prior to readdir.

Fixes: 0de1f4c6f6c0 ("Add way to query server fs info for smb3")
Signed-off-by: David Disseldorp 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

CIFS: fix mapping of SFM_SPACE and SFM_PERIOD

2017-05-20T12:27:01+00:00

commit b704e70b7cf48f9b67c07d585168e102dfa30bb4 upstream.

- trailing space maps to 0xF028
- trailing period maps to 0xF029

This fix corrects the mapping of file names which have a trailing character
that would otherwise be illegal (period or space) but is allowed by POSIX.

Signed-off-by: Bjoern Jacke 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

SMB3: Work around mount failure when using SMB3 dialect to Macs

2017-05-20T12:27:01+00:00

commit 7db0a6efdc3e990cdfd4b24820d010e9eb7890ad upstream.

Macs send the maximum buffer size in response on ioctl to validate
negotiate security information, which causes us to fail the mount
as the response buffer is larger than the expected response.

Changed ioctl response processing to allow for padding of validate
negotiate ioctl response and limit the maximum response size to
maximum buffer size.

Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

Set unicode flag on cifs echo request to avoid Mac error

2017-05-20T12:27:01+00:00

commit 26c9cb668c7fbf9830516b75d8bee70b699ed449 upstream.

Mac requires the unicode flag to be set for cifs, even for the smb
echo request (which doesn't have strings).

Without this Mac rejects the periodic echo requests (when mounting
with cifs) that we use to check if server is down

Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

fs/block_dev: always invalidate cleancache in invalidate_bdev()

2017-05-20T12:27:01+00:00

commit a5f6a6a9c72eac38a7fadd1a038532bc8516337c upstream.

invalidate_bdev() calls cleancache_invalidate_inode() iff ->nrpages != 0
which doen't make any sense.

Make sure that invalidate_bdev() always calls cleancache_invalidate_inode()
regardless of mapping->nrpages value.

Fixes: c515e1fd361c ("mm/fs: add hooks to support cleancache")
Link: http://lkml.kernel.org/r/20170424164135.22350-3-aryabinin@virtuozzo.com
Signed-off-by: Andrey Ryabinin 
Reviewed-by: Jan Kara 
Acked-by: Konrad Rzeszutek Wilk 
Cc: Alexander Viro 
Cc: Ross Zwisler 
Cc: Jens Axboe 
Cc: Johannes Weiner 
Cc: Alexey Kuznetsov 
Cc: Christoph Hellwig 
Cc: Nikolay Borisov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ceph: fix memory leak in __ceph_setxattr()

2017-05-20T12:27:01+00:00

commit eeca958dce0a9231d1969f86196653eb50fcc9b3 upstream.

The ceph_inode_xattr needs to be released when removing an xattr.  Easily
reproducible running the 'generic/020' test from xfstests or simply by
doing:

  attr -s attr0 -V 0 /mnt/test && attr -r attr0 /mnt/test

While there, also fix the error path.

Here's the kmemleak splat:

unreferenced object 0xffff88001f86fbc0 (size 64):
  comm "attr", pid 244, jiffies 4294904246 (age 98.464s)
  hex dump (first 32 bytes):
    40 fa 86 1f 00 88 ff ff 80 32 38 1f 00 88 ff ff  @........28.....
    00 01 00 00 00 00 ad de 00 02 00 00 00 00 ad de  ................
  backtrace:
    [] kmemleak_alloc+0x49/0xa0
    [] kmem_cache_alloc+0x9b/0xf0
    [] __ceph_setxattr+0x17e/0x820
    [] ceph_set_xattr_handler+0x37/0x40
    [] __vfs_removexattr+0x4b/0x60
    [] vfs_removexattr+0x77/0xd0
    [] removexattr+0x41/0x60
    [] path_removexattr+0x75/0xa0
    [] SyS_lremovexattr+0xb/0x10
    [] entry_SYSCALL_64_fastpath+0x13/0x94
    [] 0xffffffffffffffff

Signed-off-by: Luis Henriques 
Reviewed-by: "Yan, Zheng" 
Signed-off-by: Ilya Dryomov 
Signed-off-by: Greg Kroah-Hartman

fs/xattr.c: zero out memory copied to userspace in getxattr

2017-05-20T12:27:01+00:00

commit 81be3dee96346fbe08c31be5ef74f03f6b63cf68 upstream.

getxattr uses vmalloc to allocate memory if kzalloc fails.  This is
filled by vfs_getxattr and then copied to the userspace.  vmalloc,
however, doesn't zero out the memory so if the specific implementation
of the xattr handler is sloppy we can theoretically expose a kernel
memory.  There is no real sign this is really the case but let's make
sure this will not happen and use vzalloc instead.

Fixes: 779302e67835 ("fs/xattr.c:getxattr(): improve handling of allocation failures")
Link: http://lkml.kernel.org/r/20170306103327.2766-1-mhocko@kernel.org
Acked-by: Kees Cook 
Reported-by: Vlastimil Babka 
Signed-off-by: Michal Hocko 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

ext4: evict inline data when writing to memory map

2017-05-20T12:27:01+00:00

commit 7b4cc9787fe35b3ee2dfb1c35e22eafc32e00c33 upstream.

Currently the case of writing via mmap to a file with inline data is not
handled.  This is maybe a rare case since it requires a writable memory
map of a very small file, but it is trivial to trigger with on
inline_data filesystem, and it causes the
'BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA));' in
ext4_writepages() to be hit:

    mkfs.ext4 -O inline_data /dev/vdb
    mount /dev/vdb /mnt
    xfs_io -f /mnt/file \
	-c 'pwrite 0 1' \
	-c 'mmap -w 0 1m' \
	-c 'mwrite 0 1' \
	-c 'fsync'

	kernel BUG at fs/ext4/inode.c:2723!
	invalid opcode: 0000 [#1] SMP
	CPU: 1 PID: 2532 Comm: xfs_io Not tainted 4.11.0-rc1-xfstests-00301-g071d9acf3d1f #633
	Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-20170228_101828-anatol 04/01/2014
	task: ffff88003d3a8040 task.stack: ffffc90000300000
	RIP: 0010:ext4_writepages+0xc89/0xf8a
	RSP: 0018:ffffc90000303ca0 EFLAGS: 00010283
	RAX: 0000028410000000 RBX: ffff8800383fa3b0 RCX: ffffffff812afcdc
	RDX: 00000a9d00000246 RSI: ffffffff81e660e0 RDI: 0000000000000246
	RBP: ffffc90000303dc0 R08: 0000000000000002 R09: 869618e8f99b4fa5
	R10: 00000000852287a2 R11: 00000000a03b49f4 R12: ffff88003808e698
	R13: 0000000000000000 R14: 7fffffffffffffff R15: 7fffffffffffffff
	FS:  00007fd3e53094c0(0000) GS:ffff88003e400000(0000) knlGS:0000000000000000
	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
	CR2: 00007fd3e4c51000 CR3: 000000003d554000 CR4: 00000000003406e0
	Call Trace:
	 ? _raw_spin_unlock+0x27/0x2a
	 ? kvm_clock_read+0x1e/0x20
	 do_writepages+0x23/0x2c
	 ? do_writepages+0x23/0x2c
	 __filemap_fdatawrite_range+0x80/0x87
	 filemap_write_and_wait_range+0x67/0x8c
	 ext4_sync_file+0x20e/0x472
	 vfs_fsync_range+0x8e/0x9f
	 ? syscall_trace_enter+0x25b/0x2d0
	 vfs_fsync+0x1c/0x1e
	 do_fsync+0x31/0x4a
	 SyS_fsync+0x10/0x14
	 do_syscall_64+0x69/0x131
	 entry_SYSCALL64_slow_path+0x25/0x25

We could try to be smart and keep the inline data in this case, or at
least support delayed allocation when allocating the block, but these
solutions would be more complicated and don't seem worthwhile given how
rare this case seems to be.  So just fix the bug by calling
ext4_convert_inline_data() when we're asked to make a page writable, so
that any inline data gets evicted, with the block allocated immediately.

Reported-by: Nick Alcock 
Reviewed-by: Andreas Dilger 
Signed-off-by: Eric Biggers 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

block: get rid of blk_integrity_revalidate()

2017-05-14T11:32:59+00:00

commit 19b7ccf8651df09d274671b53039c672a52ad84d upstream.

Commit 25520d55cdb6 ("block: Inline blk_integrity in struct gendisk")
introduced blk_integrity_revalidate(), which seems to assume ownership
of the stable pages flag and unilaterally clears it if no blk_integrity
profile is registered:

    if (bi->profile)
            disk->queue->backing_dev_info->capabilities |=
                    BDI_CAP_STABLE_WRITES;
    else
            disk->queue->backing_dev_info->capabilities &=
                    ~BDI_CAP_STABLE_WRITES;

It's called from revalidate_disk() and rescan_partitions(), making it
impossible to enable stable pages for drivers that support partitions
and don't use blk_integrity: while the call in revalidate_disk() can be
trivially worked around (see zram, which doesn't support partitions and
hence gets away with zram_revalidate_disk()), rescan_partitions() can
be triggered from userspace at any time.  This breaks rbd, where the
ceph messenger is responsible for generating/verifying CRCs.

Since blk_integrity_{un,}register() "must" be used for (un)registering
the integrity profile with the block layer, move BDI_CAP_STABLE_WRITES
setting there.  This way drivers that call blk_integrity_register() and
use integrity infrastructure won't interfere with drivers that don't
but still want stable pages.

Fixes: 25520d55cdb6 ("block: Inline blk_integrity in struct gendisk")
Cc: "Martin K. Petersen" 
Cc: Christoph Hellwig 
Cc: Mike Snitzer 
Tested-by: Dan Williams 
Signed-off-by: Ilya Dryomov 
[idryomov@gmail.com: backport to < 4.11: bdi is embedded in queue]
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman