linux-stable.git/drivers/staging, branch v5.0.1

staging: android: ashmem: Avoid range_alloc() allocation with ashmem_mutex held.

2019-03-10T06:08:58+00:00

commit ecd182cbf4e107928077866399100228d2359c60 upstream.

ashmem_pin() is calling range_shrink() without checking whether
range_alloc() succeeded. Also, doing memory allocation with ashmem_mutex
held should be avoided because ashmem_shrink_scan() tries to hold it.

Therefore, move memory allocation for range_alloc() to ashmem_pin_unpin()
and make range_alloc() not to fail.

This patch is mostly meant for backporting purpose for fuzz testing on
stable/distributor kernels, for there is a plan to remove this code in
near future.

Signed-off-by: Tetsuo Handa 
Cc: stable@vger.kernel.org
Reviewed-by: Joel Fernandes 
Signed-off-by: Greg Kroah-Hartman

staging: android: ashmem: Don't call fallocate() with ashmem_mutex held.

2019-03-10T06:08:58+00:00

commit fb4415a12632f0b9078a0aa80c16745d48fcfc74 upstream.

syzbot is hitting lockdep warnings [1][2][3]. This patch tries to fix
the warning by eliminating ashmem_shrink_scan() => {shmem|vfs}_fallocate()
sequence.

[1] https://syzkaller.appspot.com/bug?id=87c399f6fa6955006080b24142e2ce7680295ad4
[2] https://syzkaller.appspot.com/bug?id=7ebea492de7521048355fc84210220e1038a7908
[3] https://syzkaller.appspot.com/bug?id=e02419c12131c24e2a957ea050c2ab6dcbbc3270

Reported-by: syzbot 
Reported-by: syzbot 
Reported-by: syzbot 
Signed-off-by: Tetsuo Handa 
Cc: stable@vger.kernel.org
Acked-by: Joel Fernandes (Google) 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: fix sys heap pool's gfp_flags

2019-03-10T06:08:58+00:00

commit 9bcf065e28122588a6cbee08cf847826dacbb438 upstream.

In the first loop, gfp_flags will be modified to high_order_gfp_flags,
and there will be no chance to change back to low_order_gfp_flags.

Fixes: e7f63771b60e ("ION: Sys_heap: Add cached pool to spead up cached buffer alloc")
Signed-off-by: Qing Xia 
Cc: stable 
Signed-off-by: Jing Xia 
Reviewed-by: Yuming Han 
Reviewed-by: Zhaoyang Huang 
Reviewed-by: Orson Zhai 
Signed-off-by: Greg Kroah-Hartman

staging: wilc1000: fix to set correct value for 'vif_num'

2019-03-10T06:08:58+00:00

commit dda037057a572f5c82ac2499eb4e6fb17600ba3e upstream.

Set correct value in '->vif_num' for the total number of interfaces and
set '->idx' value using 'i'.

Fixes: 735bb39ca3be ("staging: wilc1000: simplify vif[i]->ndev accesses")
Fixes: 0e490657c721 ("staging: wilc1000: Fix problem with wrong vif index")
Cc: 
Suggested-by: Dan Carpenter 
Reviewed-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

staging: comedi: ni_660x: fix missing break in switch statement

2019-03-10T06:08:58+00:00

commit 479826cc86118e0d87e5cefb3df5b748e0480924 upstream.

Add missing break statement in order to prevent the code from falling
through to the default case and return -EINVAL every time.

This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.

Fixes: aa94f2888825 ("staging: comedi: ni_660x: tidy up ni_660x_set_pfi_routing()")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
Reviewed-by: Ian Abbott 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix illegal address access under memory pressure

2019-03-10T06:08:58+00:00

commit 1e5ceeab6929585512c63d05911d6657064abf7b upstream.

Considering a read request with two decompressed file pages,
If a decompression work cannot be started on the previous page
due to memory pressure but in-memory LTP map lookup is done,
builder->work should be still NULL.

Moreover, if the current page also belongs to the same map,
it won't try to start the decompression work again and then
run into trouble.

This patch aims to solve the above issue only with little changes
as much as possible in order to make the fix backport easier.

kernel message is:
<4>[1051408.015930s]SLUB: Unable to allocate memory on node -1, gfp=0x2408040(GFP_NOFS|__GFP_ZERO)
<4>[1051408.015930s]  cache: erofs_compress, object size: 144, buffer size: 144, default order: 0, min order: 0
<4>[1051408.015930s]  node 0: slabs: 98, objs: 2744, free: 0
  * Cannot allocate the decompression work

<3>[1051408.015960s]erofs: z_erofs_vle_normalaccess_readpages, readahead error at page 1008 of nid 5391488
  * Note that the previous page was failed to read

<0>[1051408.015960s]Internal error: Accessing user space memory outside uaccess.h routines: 96000005 [#1] PREEMPT SMP
...
<4>[1051408.015991s]Hardware name: kirin710 (DT)
...
<4>[1051408.016021s]PC is at z_erofs_vle_work_add_page+0xa0/0x17c
<4>[1051408.016021s]LR is at z_erofs_do_read_page+0x12c/0xcf0
...
<4>[1051408.018096s][] z_erofs_vle_work_add_page+0xa0/0x17c
<4>[1051408.018096s][] z_erofs_vle_normalaccess_readpages+0x1a0/0x37c
<4>[1051408.018096s][] read_pages+0x70/0x190
<4>[1051408.018127s][] __do_page_cache_readahead+0x194/0x1a8
<4>[1051408.018127s][] filemap_fault+0x398/0x684
<4>[1051408.018127s][] __do_fault+0x8c/0x138
<4>[1051408.018127s][] handle_pte_fault+0x730/0xb7c
<4>[1051408.018127s][] __handle_mm_fault+0xac/0xf4
<4>[1051408.018157s][] handle_mm_fault+0x7c/0x118
<4>[1051408.018157s][] do_page_fault+0x354/0x474
<4>[1051408.018157s][] do_translation_fault+0x40/0x48
<4>[1051408.018157s][] do_mem_abort+0x80/0x100
<4>[1051408.018310s]---[ end trace 9f4009a3283bd78b ]---

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
Reviewed-by: Chao Yu 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix race of initializing xattrs of a inode at the same time

2019-03-10T06:08:58+00:00

commit 62dc45979f3f8cb0ea67302a93bff686f0c46c5a upstream.

In real scenario, there could be several threads accessing xattrs
of the same xattr-uninitialized inode, and init_inode_xattrs()
almost at the same time.

That's actually an unexpected behavior, this patch closes the race.

Fixes: b17500a0fdba ("staging: erofs: introduce xattr & acl support")
Cc:  # 4.19+
Reviewed-by: Chao Yu 
Signed-off-by: Gao Xiang 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix memleak of inode's shared xattr array

2019-03-10T06:08:58+00:00

commit 3b1b5291f79d040d549d7c746669fc30e8045b9b upstream.

If it fails to read a shared xattr page, the inode's shared xattr array
is not freed. The next time the inode's xattr is accessed, the previously
allocated array is leaked.

Signed-off-by: Sheng Yong 
Fixes: b17500a0fdba ("staging: erofs: introduce xattr & acl support")
Cc:  # 4.19+
Reviewed-by: Gao Xiang 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix fast symlink w/o xattr when fs xattr is on

2019-03-10T06:08:58+00:00

commit 7077fffcb0b0b65dc75e341306aeef4d0e7f2ec6 upstream.

Currently, this will hit a BUG_ON for these symlinks as follows:

- kernel message
------------[ cut here ]------------
kernel BUG at drivers/staging/erofs/xattr.c:59!
SMP PTI
CPU: 1 PID: 1170 Comm: getllxattr Not tainted 4.20.0-rc6+ #92
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
RIP: 0010:init_inode_xattrs+0x22b/0x270
Code: 48 0f 45 ea f0 ff 4d 34 74 0d 41 83 4c 24 e0 01 31 c0 e9 00 fe ff ff 48 89 ef e8 e0 31 9e ff eb e9 89 e8 e9 ef fd ff ff 0f 0$
 <0f> 0b 48 89 ef e8 fb f6 9c ff 48 8b 45 08 a8 01 75 24 f0 ff 4d 34
RSP: 0018:ffffa03ac026bdf8 EFLAGS: 00010246
------------[ cut here ]------------
...
Call Trace:
 erofs_listxattr+0x30/0x2c0
 ? selinux_inode_listxattr+0x5a/0x80
 ? kmem_cache_alloc+0x33/0x170
 ? security_inode_listxattr+0x27/0x40
 listxattr+0xaf/0xc0
 path_listxattr+0x5a/0xa0
 do_syscall_64+0x43/0xf0
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
...
---[ end trace 3c24b49408dc0c72 ]---

Fix it by checking ->xattr_isize in init_inode_xattrs(),
and it also fixes improper return value -ENOTSUPP
(it should be -ENODATA if xattr is enabled) for those inodes.

Fixes: b17500a0fdba ("staging: erofs: introduce xattr & acl support")
Cc:  # 4.19+
Reported-by: Li Guifu 
Tested-by: Li Guifu 
Reviewed-by: Chao Yu 
Signed-off-by: Gao Xiang 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: fix mis-acted TAIL merging behavior

2019-03-10T06:08:57+00:00

commit a112152f6f3a2a88caa6f414d540bd49e406af60 upstream.

EROFS has an optimized path called TAIL merging, which is designed
to merge multiple reads and the corresponding decompressions into
one if these requests read continuous pages almost at the same time.

In general, it behaves as follows:
 ________________________________________________________________
  ... |  TAIL  .  HEAD  |  PAGE  |  PAGE  |  TAIL    . HEAD | ...
 _____|_combined page A_|________|________|_combined page B_|____
        1  ]  ->  [  2                          ]  ->  [ 3
If the above three reads are requested in the order 1-2-3, it will
generate a large work chain rather than 3 individual work chains
to reduce scheduling overhead and boost up sequential read.

However, if Read 2 is processed slightly earlier than Read 1,
currently it still generates 2 individual work chains (chain 1, 2)
but it does in-place decompression for combined page A, moreover,
if chain 2 decompresses ahead of chain 1, it will be a race and
lead to corrupted decompressed page. This patch fixes it.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
Reviewed-by: Chao Yu 
Signed-off-by: Greg Kroah-Hartman