linux-stable.git/drivers/staging/android, branch v4.4.136

staging: ion : Donnot wakeup kswapd in ion system alloc

2018-04-29T05:50:01+00:00

commit 2ef230531ee171a475fc3ddad5516dd7e09a8a77 upstream.

Since ion alloc can be called by userspace,eg gralloc.
When it is called frequently, the efficiency of kswapd is
to low. And the reclaimed memory is too lower. In this way,
the kswapd can use to much cpu resources.

With 3.5GB DMA Zone and 0.5 Normal Zone.

pgsteal_kswapd_dma 9364140
pgsteal_kswapd_normal 7071043
pgscan_kswapd_dma 10428250
pgscan_kswapd_normal 37840094

With this change the reclaim ratio has greatly improved
18.9% -> 72.5%

Signed-off-by: Chen Feng 
Signed-off-by: Lu bing 
Reviewed-by: Laura Abbott 
Cc: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman

staging: android: ashmem: Fix possible deadlock in ashmem_ioctl

2018-03-24T09:58:40+00:00

commit 740a5759bf222332fbb5eda42f89aa25ba38f9b2 upstream.

ashmem_mutex may create a chain of dependencies like:

CPU0                                    CPU1
 mmap syscall                           ioctl syscall
 -> mmap_sem (acquired)                 -> ashmem_ioctl
 -> ashmem_mmap                            -> ashmem_mutex (acquired)
    -> ashmem_mutex (try to acquire)       -> copy_from_user
                                              -> mmap_sem (try to acquire)

There is a lock odering problem between mmap_sem and ashmem_mutex causing
a lockdep splat[1] during a syzcaller test. This patch fixes the problem
by move copy_from_user out of ashmem_mutex.

[1] https://www.spinics.net/lists/kernel/msg2733200.html

Fixes: ce8a3a9e76d0 (staging: android: ashmem: Fix a race condition in pin ioctls)
Reported-by: syzbot+d7a918a7a8e1c952bc36@syzkaller.appspotmail.com
Signed-off-by: Yisheng Xie 
Cc: "Joel Fernandes (Google)" 
Signed-off-by: Greg Kroah-Hartman

staging: android: ashmem: Fix lockdep issue during llseek

2018-03-18T10:17:53+00:00

commit cb57469c9573f6018cd1302953dd45d6e05aba7b upstream.

ashmem_mutex create a chain of dependencies like so:

(1)
mmap syscall ->
  mmap_sem ->  (acquired)
  ashmem_mmap
  ashmem_mutex (try to acquire)
  (block)

(2)
llseek syscall ->
  ashmem_llseek ->
  ashmem_mutex ->  (acquired)
  inode_lock ->
  inode->i_rwsem (try to acquire)
  (block)

(3)
getdents ->
  iterate_dir ->
  inode_lock ->
  inode->i_rwsem   (acquired)
  copy_to_user ->
  mmap_sem         (try to acquire)

There is a lock ordering created between mmap_sem and inode->i_rwsem
causing a lockdep splat [2] during a syzcaller test, this patch fixes
the issue by unlocking the mutex earlier. Functionally that's Ok since
we don't need to protect vfs_llseek.

[1] https://patchwork.kernel.org/patch/10185031/
[2] https://lkml.org/lkml/2018/1/10/48

Acked-by: Todd Kjos 
Cc: Arve Hjonnevag 
Cc: stable@vger.kernel.org
Reported-by: syzbot+8ec30bb7bf1a981a2012@syzkaller.appspotmail.com
Signed-off-by: Joel Fernandes 
Acked-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman

staging: android: ashmem: Fix a race condition in pin ioctls

2018-02-25T10:03:38+00:00

commit ce8a3a9e76d0193e2e8d74a06d275b3c324ca652 upstream.

ashmem_pin_unpin() reads asma->file and asma->size before taking the
ashmem_mutex, so it can race with other operations that modify them.

Build-tested only.

Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

staging: android: ashmem: fix a race condition in ASHMEM_SET_SIZE ioctl

2018-01-17T08:35:32+00:00

commit 443064cb0b1fb4569fe0a71209da7625129fb760 upstream.

A lock-unlock is missing in ASHMEM_SET_SIZE ioctl which can result in a
race condition when mmap is called. After the !asma->file check, before
setting asma->size, asma->file can be set in mmap. That would result in
having different asma->size than the mapped memory size. Combined with
ASHMEM_UNPIN ioctl and shrinker invocation, this can result in memory
corruption.

Signed-off-by: Viktor Slavkovic 
Signed-off-by: Greg Kroah-Hartman

staging/android/ion : fix a race condition in the ion driver

2017-04-30T03:49:29+00:00

commit 9590232bb4f4cc824f3425a6e1349afbe6d6d2b7 upstream.

There is a use-after-free problem in the ion driver.
This is caused by a race condition in the ion_ioctl()
function.

A handle has ref count of 1 and two tasks on different
cpus calls ION_IOC_FREE simultaneously.

cpu 0                                   cpu 1
-------------------------------------------------------
ion_handle_get_by_id()
(ref == 2)
                            ion_handle_get_by_id()
                            (ref == 3)

ion_free()
(ref == 2)

ion_handle_put()
(ref == 1)

                            ion_free()
                            (ref == 0 so ion_handle_destroy() is
                            called
                            and the handle is freed.)

                            ion_handle_put() is called and it
                            decreases the slub's next free pointer

The problem is detected as an unaligned access in the
spin lock functions since it uses load exclusive
 instruction. In some cases it corrupts the slub's
free pointer which causes a mis-aligned access to the
next free pointer.(kmalloc returns a pointer like
ffffc0745b4580aa). And it causes lots of other
hard-to-debug problems.

This symptom is caused since the first member in the
ion_handle structure is the reference count and the
ion driver decrements the reference after it has been
freed.

To fix this problem client->lock mutex is extended
to protect all the codes that uses the handle.

Signed-off-by: Eun Taik Lee 
Reviewed-by: Laura Abbott 
Cc: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman 

index 7ff2a7ec871f..33b390e7ea31

staging: android: ashmem: lseek failed due to no FMODE_LSEEK.

2017-04-12T10:38:33+00:00

commit 97fbfef6bd597888485b653175fb846c6998b60c upstream.

vfs_llseek will check whether the file mode has
FMODE_LSEEK, no return failure. But ashmem can be
lseek, so add FMODE_LSEEK to ashmem file.

Comment From Greg Hackmann:
	ashmem_llseek() passes the llseek() call through to the backing
	shmem file.  91360b02ab48 ("ashmem: use vfs_llseek()") changed
	this from directly calling the file's llseek() op into a VFS
	layer call.  This also adds a check for the FMODE_LSEEK bit, so
	without that bit ashmem_llseek() now always fails with -ESPIPE.

Fixes: 91360b02ab48 ("ashmem: use vfs_llseek()")
Signed-off-by: Shuxiao Zhang 
Tested-by: Greg Hackmann 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: Set the length of the DMA sg entries in buffer

2016-04-20T06:42:16+00:00

commit 70bc916b2c80913753fb188d4daee50a64d21ba0 upstream.

ion_buffer_create() will allocate a buffer and then create a DMA
mapping for it, but it forgot to set the length of the page entries.

Signed-off-by: Liviu Dudau 
Signed-off-by: Jon Medhurst 
Acked-by: Laura Abbott 
Cc: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion_test: fix check of platform_device_register_simple() error code

2016-04-12T16:08:48+00:00

commit ccbc2a9e7878ff09bcaed4893c2a2d3adbb797e2 upstream.

On error platform_device_register_simple() returns ERR_PTR() value,
check for NULL always fails. The change corrects the check itself and
propagates the returned error upwards.

Fixes: 81fb0b901397 ("staging: android: ion_test: unregister the platform device")
Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Greg Kroah-Hartman

Revert "scatterlist: use sg_phys()"

2015-12-15T20:54:06+00:00

commit db0fa0cb0157 "scatterlist: use sg_phys()" did replacements of
the form:

    phys_addr_t phys = page_to_phys(sg_page(s));
    phys_addr_t phys = sg_phys(s) & PAGE_MASK;

However, this breaks platforms where sizeof(phys_addr_t) >
sizeof(unsigned long).  Revert for 4.3 and 4.4 to make room for a
combined helper in 4.5.

Cc: 
Cc: Jens Axboe 
Cc: Christoph Hellwig 
Cc: Russell King 
Cc: David Woodhouse 
Cc: Andrew Morton 
Fixes: db0fa0cb0157 ("scatterlist: use sg_phys()")
Suggested-by: Joerg Roedel 
Reported-by: Vitaly Lavrov 
Signed-off-by: Dan Williams