linux-stable.git/drivers/staging/android, branch linux-3.14.y

staging: ion: fix corruption of ion_import_dma_buf

2015-10-22T21:39:19+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

staging: binder: Fix death notifications

2014-02-21T20:30:54+00:00

The change (008fa749e0fe5b2fffd20b7fe4891bb80d072c6a) that moved the
node release code to a separate function broke death notifications in
some cases. When it encountered a reference without a death
notification request, it would skip looking at the remaining
references, and therefore fail to send death notifications for them.

Cc: Colin Cross 
Cc: Android Kernel Team 
Cc: stable  # 3.10
Signed-off-by: Arve Hjønnevåg 
Signed-off-by: John Stultz 
Signed-off-by: Jeremy Compostella 
Signed-off-by: Greg Kroah-Hartman

gpu: ion: dereferencing an ERR_PTR

2014-02-07T19:08:46+00:00

We dereference "heap->task" before checking if it's an ERR_PTR.

Fixes: ea313b5f88ed ('gpu: ion: Also shrink memory cached in the deferred free list')
Signed-off-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman

staging: android: ion: dummy: fix an error code

2014-02-07T19:08:46+00:00

We should be returning -ENOMEM here instead of zero.

Signed-off-by: Dan Carpenter 
Signed-off-by: Greg Kroah-Hartman

staging: android: sync: Signal pt before sync_timeline object gets destroyed

2014-02-07T17:36:27+00:00

There is a race condition

Assume we have *one* sync_fence object, with *one* sync_pt
which belongs to *one* sync_timeline, given this condition,
sync_timeline->kref will have two counts, one for sync_timeline
(implicit) and another for sync_pt.

Assume following is the situation on CPU

Theead-1 : (Thread which calls sync_timeline_destroy())
  -> (some function calls)
   -> sync_timeline_destory()
    -> sync_timeline_signal() (CPU is inside this
function after putting reference to sync_timeline)

At this time Thread-2 comes and does following

Thread-2 : (fclose on fence fd)
> sync_fence_release() -> because of fclose() on fence object
 -> sync_fence_free()
  -> sync_pt_free()
   -> kref_put(&pt->parent->kref, sync_timeline_free);
    -> sync_timeline_free() (CPU is inside this because
this time kref will be zero after _put)

Thread-2 will free sync_timeline object before Thread-1
has finished its work inside sync_timeline_signal.

With this change we signals all sync_pt before putting
reference to sync_timeline object.

Cc: Colin Cross 
Cc: Android Kernel Team 
Signed-off-by: Prakash Kamliya 
[jstultz: minor commit subject tweak]
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

staging: ion: Fix build warning

2014-02-07T17:03:16+00:00

Add #include  to fix the following warning seen
with gcc 4.7.3:

In file included from drivers/staging/android/ion/ion_heap.c:26:0:
drivers/staging/android/ion/ion_priv.h:358:21: warning: ‘struct device’ declared inside parameter list [enabled by default]
drivers/staging/android/ion/ion_priv.h:358:21: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]

Cc: Colin Cross 
Cc: Android Kernel Team 
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

staging: ion: Fix ION_IOC_FREE compat ioctl

2014-02-07T17:03:16+00:00

The compat ioctl for ION_IOC_FREE currently passes allocation data
instead of the free data. Correct this.

Cc: Colin Cross 
Cc: Android Kernel Team 
Signed-off-by: Laura Abbott 
[jstultz: Folded in a small build fix]
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

staging: ion: Fix overflow and list bugs in system heap

2014-02-07T17:03:16+00:00

Fix a few bugs in ion_system_heap:

Initialize the list node in the info block.

Don't store size_remaining in a signed long, allocating >2GB
could overflow, resulting in a call to sg_alloc_table with
nents=0 which panics.  alloc_largest_available will never
return a block larger than size_remanining, so it can never
go negative.

Limit a single allocation to half of all memory.  Prevents a
large allocation from taking down the whole system.

Cc: Colin Cross 
Cc: Android Kernel Team 
Signed-off-by: Colin Cross 
[jstultz: Minor commit subject tweak]
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

staging: ashmem: Avoid deadlock between read and mmap calls

2014-02-07T17:03:16+00:00

Avoid holding ashmem_mutex across code that can page fault.  Page faults
grab the mmap_sem for the process, which are also held by mmap calls
prior to calling ashmem_mmap, which locks ashmem_mutex.  The reversed
order of locking between the two can deadlock.

The calls that can page fault are read() and the ASHMEM_SET_NAME and
ASHMEM_GET_NAME ioctls.  Move the code that accesses userspace pages
outside the ashmem_mutex.

Cc: Colin Cross 
Cc: Android Kernel Team 
Signed-off-by: Todd Poynor 
[jstultz: minor commit message tweaks]
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

staging: sync: Fix a race condition between release_obj and print_obj

2014-02-07T17:03:16+00:00

Before this change, a timeline would only be removed from the timeline
list *after* the sync driver had its release_obj() called. However, the
driver's release_obj() may free resources needed by print_obj().

Although the timeline list is locked when print_obj() is called, it is
not locked when release_obj() is called. If one CPU was in print_obj()
when another was in release_obj(), the print_obj() may make unsafe
accesses.

It is not actually necessary to hold the timeline list lock when calling
release_obj() if the call is made after the timeline is unlinked from
the list, since there is no possibility another thread could be in --
or enter -- print_obj() for that timeline.

This change moves the release_obj() call to after the timeline is
unlinked, preventing the above race from occurring.

Cc: Colin Cross 
Cc: Android Kernel Team 
Signed-off-by: Alistair Strachan 
[jstultz: minor commit subject tweak]
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman