linux-stable.git/drivers/staging/android/ion, branch v3.16.78

staging: android: ion: Return an ERR_PTR in ion_map_kernel

2018-11-20T18:05:27+00:00

commit 0a2bc00341dcfcc793c0dbf4f8d43adf60458b05 upstream.

The expected return value from ion_map_kernel is an ERR_PTR. The error
path for a vmalloc failure currently just returns NULL, triggering
a warning in ion_buffer_kmap_get. Encode the vmalloc failure as an ERR_PTR.

Reported-by: syzbot+55b1d9f811650de944c6@syzkaller.appspotmail.com
Signed-off-by: Laura Abbott 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

staging: android: ion: Switch to pr_warn_once in ion_buffer_destroy

2018-11-20T18:04:55+00:00

commit 45ad559a29629cb1c64ee636563c69b71524f077 upstream.

Syzbot reported yet another warning with Ion:

WARNING: CPU: 0 PID: 1467 at drivers/staging/android/ion/ion.c:122
ion_buffer_destroy+0xd4/0x190 drivers/staging/android/ion/ion.c:122
Kernel panic - not syncing: panic_on_warn set ...

This is catching that a buffer was freed with an existing kernel mapping
still present. This can be easily be triggered from userspace by calling
DMA_BUF_SYNC_START without calling DMA_BUF_SYNC_END. Switch to a single
pr_warn_once to indicate the error without being disruptive.

Reported-by: syzbot+cd8bcd40cb049efa2770@syzkaller.appspotmail.com
Reported-by: syzbot 
Signed-off-by: Laura Abbott 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

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

2017-02-23T03:54:47+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 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Ben Hutchings

staging: ion: fix corruption of ion_import_dma_buf

2015-10-09T13:41:06+00:00

commit 6fa92e2bcf6390e64895b12761e851c452d87bd8 upstream.

we found this issue but still exit in lastest kernel. Simply
keep ion_handle_create under mutex_lock to avoid this race.

WARNING: CPU: 2 PID: 2648 at drivers/staging/android/ion/ion.c:512 ion_handle_add+0xb4/0xc0()
ion_handle_add: buffer already found.
Modules linked in: iwlmvm iwlwifi mac80211 cfg80211 compat
CPU: 2 PID: 2648 Comm: TimedEventQueue Tainted: G        W    3.14.0 #7
 00000000 00000000 9a3efd2c 80faf273 9a3efd6c 9a3efd5c 80935dc9 811d7fd3
 9a3efd88 00000a58 812208a0 00000200 80e128d4 80e128d4 8d4ae00c a8cd8600
 a8cd8094 9a3efd74 80935e0e 00000009 9a3efd6c 811d7fd3 9a3efd88 9a3efd9c
Call Trace:
  [<80faf273>] dump_stack+0x48/0x69
  [<80935dc9>] warn_slowpath_common+0x79/0x90
  [<80e128d4>] ? ion_handle_add+0xb4/0xc0
  [<80e128d4>] ? ion_handle_add+0xb4/0xc0
  [<80935e0e>] warn_slowpath_fmt+0x2e/0x30
  [<80e128d4>] ion_handle_add+0xb4/0xc0
  [<80e144cc>] ion_import_dma_buf+0x8c/0x110
  [<80c517c4>] reg_init+0x364/0x7d0
  [<80993363>] ? futex_wait+0x123/0x210
  [<80992e0e>] ? get_futex_key+0x16e/0x1e0
  [<8099308f>] ? futex_wake+0x5f/0x120
  [<80c51e19>] vpu_service_ioctl+0x1e9/0x500
  [<80994aec>] ? do_futex+0xec/0x8e0
  [<80971080>] ? prepare_to_wait_event+0xc0/0xc0
  [<80c51c30>] ? reg_init+0x7d0/0x7d0
  [<80a22562>] do_vfs_ioctl+0x2d2/0x4c0
  [<80b198ad>] ? inode_has_perm.isra.41+0x2d/0x40
  [<80b199cf>] ? file_has_perm+0x7f/0x90
  [<80b1a5f7>] ? selinux_file_ioctl+0x47/0xf0
  [<80a227a8>] SyS_ioctl+0x58/0x80
  [<80fb45e8>] syscall_call+0x7/0x7
  [<80fb0000>] ? mmc_do_calc_max_discard+0xab/0xe4

Fixes: 83271f626 ("ion: hold reference to handle...")
Signed-off-by: Shawn Lin 
Reviewed-by: Laura Abbott 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Luis Henriques

staging: ion: shrink highmem pages on kswapd

2014-05-29T20:40:46+00:00

ION system heap keeps pages in its pool for better performance. When the
system is under memory pressure, slab shrinker calls the callback
registered and then the pages pooled get freed.

When the shrinker is called, it checks gfp_mask and determines whether
the pages from highmem need to be freed or the pages from lowmem.
Usually, slab shrinker is invoked on kswapd context which gfp_mask is
always GFP_KERNEL, so only lowmem pages are released on kswapd context.
This means that highmem pages in the pool are never reclaimed until
direct reclaim occurs. This can be problematic when the page pool holds
excessive amounts of highmem.

For now, the shrinker callback cannot know exactly which zone should be
targeted for reclamation, as enough information are not passed to. Thus,
it makes sense to shrink both lowmem and highmem zone on kswapd context.

Reported-by: Wonseo Choi 
Signed-off-by: Heesub Shin 
Reviewed-by: Mitchel Humpherys 
Tested-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

staging: ion: use compound pages on high order pages for system heap

2014-05-29T20:40:33+00:00

Using compound pages relieves burden on tracking the meta information
which are currently stored in page_info.

Signed-off-by: Heesub Shin 
Reviewed-by: Mitchel Humpherys 
Tested-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

staging: ion: remove struct ion_page_pool_item

2014-05-29T20:40:33+00:00

The page pool uses an internal data structure, ion_page_pool_item, for
wrapping pooled pages and constructing a list. As the struct page
already provides ways for doing exactly the same thing, we do not need
to reinvent the wheel. This commit removes the data structure and slab
allocations for it.

Signed-off-by: Heesub Shin 
Reviewed-by: Mitchel Humpherys 
Tested-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

staging: ion: simplify ion_page_pool_total()

2014-05-29T20:40:33+00:00

ion_page_pool_total() returns the total number of pages in the pool.
Depending on the argument passed, it counts highmem pages in or not.
This commit simplifies the code lines for better readability.

Signed-off-by: Heesub Shin 
Reviewed-by: Mitchel Humpherys 
Tested-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

staging: ion: tidy up a bit

2014-05-29T20:40:33+00:00

For aesthetics and readability, rename goto labels, remove
useless code lines, and clarify function return type.

Signed-off-by: Heesub Shin 
Reviewed-by: Mitchel Humpherys 
Tested-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

staging: ion: WARN when the handle kmap_cnt is going to wrap around

2014-05-23T22:23:15+00:00

There are certain client bugs (double unmap, for example) that can cause
the handle->kmap_cnt (an unsigned int) to wrap around from zero. This
causes problems when the handle is destroyed because we have:

        while (handle->kmap_cnt)
                ion_handle_kmap_put(handle);

which takes a long time to complete when kmap_cnt starts at ~0 and can
result in a watchdog timeout.

WARN and bail when kmap_cnt is about to wrap around from zero.

Signed-off-by: Mitchel Humpherys 
Acked-by: Colin Cross 
Signed-off-by: Greg Kroah-Hartman