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

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

mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd

2015-11-07T01:50:42+00:00

__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts.  They are expected to be high priority and
have access one of two watermarks lower than "min" which can be referred
to as the "atomic reserve".  __GFP_HIGH users get access to the first
lower watermark and can be called the "high priority reserve".

Over time, callers had a requirement to not block when fallback options
were available.  Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic
reserves.

This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative.  High priority users continue to use
__GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
redefined as a caller that is willing to enter direct reclaim and wake
kswapd for background reclaim.

This patch then converts a number of sites

o __GFP_ATOMIC is used by callers that are high priority and have memory
  pools for those requests. GFP_ATOMIC uses this flag.

o Callers that have a limited mempool to guarantee forward progress clear
  __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
  into this category where kswapd will still be woken but atomic reserves
  are not used as there is a one-entry mempool to guarantee progress.

o Callers that are checking if they are non-blocking should use the
  helper gfpflags_allow_blocking() where possible. This is because
  checking for __GFP_WAIT as was done historically now can trigger false
  positives. Some exceptions like dm-crypt.c exist where the code intent
  is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
  flag manipulations.

o Callers that built their own GFP flags instead of starting with GFP_KERNEL
  and friends now also need to specify __GFP_KSWAPD_RECLAIM.

The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.

The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL.  They may
now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.

Signed-off-by: Mel Gorman 
Acked-by: Vlastimil Babka 
Acked-by: Michal Hocko 
Acked-by: Johannes Weiner 
Cc: Christoph Lameter 
Cc: David Rientjes 
Cc: Vitaly Wool 
Cc: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

staging: ion: Remove explicit NULL comparison

2015-10-25T02:26:59+00:00

Rewrite explicit NULL comparison in its simpler form.

@NULL_REPLACE@
expression e;
@@

-e == NULL
+ !e

Signed-off-by: Muhammad Falak R Wani 
Signed-off-by: Greg Kroah-Hartman

"drivers/staging: mark android/ion fcns with EXPORT_SYMBOL for tristate

2015-10-13T21:32:36+00:00

In a recent change, we made a bool into a tristate in:
"drivers/staging: make android tegra_ion.c properly tristate", since it
was self evident that was the original intention.  However on the final
link phase we'll see an allmodconfig fail with:

ERROR: "ion_device_add_heap" [drivers/staging/android/ion/tegra/tegra_ion.ko] undefined!
ERROR: "ion_heap_create" [drivers/staging/android/ion/tegra/tegra_ion.ko] undefined!
ERROR: "ion_device_create" [drivers/staging/android/ion/tegra/tegra_ion.ko] undefined!
ERROR: "ion_heap_destroy" [drivers/staging/android/ion/tegra/tegra_ion.ko] undefined!
ERROR: "ion_device_destroy" [drivers/staging/android/ion/tegra/tegra_ion.ko] undefined!

Export the above using the non GPL specific export, since that is what
the rest of the ion code base does.

Cc: Greg Kroah-Hartman 
Cc: "Arve Hjønnevåg" 
Cc: Riley Andrews 
Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Alexandre Courbot 
Cc: Markus Elfring 
Cc: devel@driverdev.osuosl.org
Cc: linux-tegra@vger.kernel.org
Reported-by: kbuild test robot 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Greg Kroah-Hartman