Staging: android: binder: Fix use-after-free bug

binder_update_page_range could read freed memory if the vma of the
selected process was freed right before the check that the vma
belongs to the mm struct it just locked.

If the vm_mm pointer in that freed vma struct had also been rewritten
with a value that matched the locked mm struct, then the code would
proceed and possibly modify the freed vma.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Backport Linux kernel 3.0 features needed for new OMAP DSS drivers
Backport the header for the OMAP4 tiler device

Stub out the places where the API change affects us, as OMAP3 doesn't
have the tiler.
Add ION memory manager driver
Integrate OMAP ION driver into OMAP3/4 board support
Initial backport of OMAP DSS composition driver
Initial changes to OMAP DSS composition driver
ION backport: adapt for old version of omap_vrfb_setup()
DSSCOMP backport: add defines used by dsscomp driver
OMAP2 DSS: disable accidentally left-over fixed VRAM hack
Fix another instance of pr_warn() -> pr_warning()
OMAP: DSS2: Add callback for tracking overlay/manager changes

This patch allows tracking when a particular overlay or manager
change has taken place, and when it is eclipsed (no longer used).

In DSS2 overlay/manager information travels through 4 stages:
1: (software) overlay/manager info
2: (software) cache (on manager->apply())
3: (hardware) shadow registers (on configure())
4: (hardware) DISPC (on vsync or go/enable)

Callback information for each settings can be passed as part of
the info structure (info->cb), which is the following struct:

struct omapdss_ovl_cb {
	void (*fn)(void *data, int id, int status);
	void *data;
};

id contains to the overlay/manager index.

If fn is NULL, no callback will take place.  Otherwise, callbacks
will be generated on programming (when settings get into the
DISPC), when the settings are displayed, and on eclipse (when settings
are overwritten by newer settings).  Depending on the stage where the
eclipse happens, a different callback is generated.

Status is one of the DSS_COMPLETION_... enum values specifying the event.

DSS_COMPLETION_ECLIPSED_SET - info was overwritten at stage 1
DSS_COMPLETION_ECLIPSED_CACHE - info was overwritten at stage 2
DSS_COMPLETION_ECLIPSED_SHADOW - info was overwritten at stage 3
DSS_COMPLETION_RELEASED - info was overwritten at stage 4 (after successfully
being displayed)DSS_COMPLETION_TORN - info was overwritten at stage 4 (before it was
successfully displayed)

DSS_COMPLETION_PROGRAMMED - info moved from stage 3 to stage 4 (this follows
the prior info's callback of DSS_COMPLETION_RELEASED/TORN)

DSS_COMPLETION_DISPLAYED - info in stage 4 has been successfully displayed.
This callback is received on every frame refresh.  If only the first display
is required, it needs to be filtered out in the callback.

You can use the DSS_COMPLETION_RELEASED flag to see if an info has been
eclipsed (so you don't have to check for all 5 values).

There is a fundamental issue with tracking DSS settings in the current
DSS2 framework.  Pipeline/manager settings are programmed first into
an info structure that stays around.  These settins can be modified
piece-by-piece - as they are done using the sysfs framework.  Theoretically,
these cause the old settings to be eclipsed by the new settings.  However,
sysfs interface is used to augment the other DSS2 users that would register
for these callbacks.  Therefore, we need to treat these partial updates
specially.  For now - if the callback function and data are the same -
a different status is used: DSS_COMPLETION_CHANGED_SET.

Now these auxiliary interfaces also apply the changes automatically, so a
similar method needs to be used at level 2.  (DSS_COMPLETION_CHANGED_CACHE)
This, however, causes callback info to stay around at the level 1
interface making it not useful for tracking the status.  We cannot
guarantee that the information is tracked from setting to release/eclipse
if future settings may end up reusing (ignorantly) the same callback info.

For now the callback info is cleared at level 1 when transferred to
level 2.  If other - callback unaware - DSS2 users modify overlay/manager
settings, (e.g. using sysfs controls in any way), they will not reset
the callback.  We err on the side of sysfs, and we will not treat a
settings application (transferring level 1 info to level 2) as eclipsed
if the level-1 callback method is empty.  This works for sysfs changes,
but we will be a missed callback if V4L2 or FB is changing the base
address, and we are using the callbacks to track buffer usage.

The other issue is using sysfs to enable/disable an overlay.  We may
get a RELEASED event on disable, but no usage callback is done on
subsequent enable because sysfs will not request a callback.

Change-Id: Iebc2551ad1d5bce94bd668cf2c885c895809d416
Signed-off-by: Lajos Molnar <molnar@ti.com>
Signed-off-by: Mark Tyler <mark.tyler@ti.com>
Add DSS_COMPLETION_CHANGED as combination of the DSS_COMPLETION_* flags
Remove out-of-place omapdss_completion stuff

This has now been added to plat/display.h where it belongs.
dsscomp/base.c: miscellaneous adaptations for 2.6.32
OMAP:DSS2: Add manager blanking support

Add manager->blank() to disable all overlays on a manager from
all the dss_cache stages.

blank() takes 2 additional arguments beyond the manager.

wait_for_vsync: to wait for vsync before flush returns.
persist: to disable subsequent applies until the display is
turned off/suspended.

if wait_for_vsync is false, blank() will flush the callbacks
in the shadow and displayed stages of the dss cache.  You may
want to use this if there are no further VSYNCS for the
display.  This is safe because the dss_cache is updated for the
blanked overlays, so it will take effect the next time configure()
is called.

Change-Id: Ic4bbd4ef73246ee89bdc8699b4bc09efffafe51f
Signed-off-by: Lajos Molnar <molnar@ti.com>
OMAP: DSS/DSSCOMP: Remove race conditions on callback setting and error handling

This fixes lockups and crashes observed during display error
injection tests.

Wrapping prior callback for managers created race condition,
where the manager settings could change between setting
the manager info and wrapping the callback.  Since callbacks
are never set on the original managers, this wrapping functionality
is removed.

The error handling pathway was also prone to race conditions as
the settings could have gotten applied between the mgr->apply failure
and the unsetting of the callback.  Therefore, created a protected
method to unregister a callback (given that it has not been applied).

Finally, callbacks were not called when set_mgr_info failed, but
mgr_apply succeeded.  This is now needed as we are not wrapping the
callback outside of set_mgr_info.

Also fixed two bugs in mgr_blank() where the apply ISR was not
registered, and where we did not wait got GO if GO was not already
present during configure().

Change-Id: Ifb4e07ea3bc17006c394517b8eb216ebfe154b73
Signed-off-by: Iliyan Malchev <malchev@google.com>
OMAP:DSS: Allow specifying which DSS callbacks to get

Add a bitmask to the callback specification.  This allows limiting
which callback to get from the DSS.

The callback function must return a new mask that is and-ed to
the existing mask.  If the mask becomes 0, no more callbacks will
be scheduled for the settings that are tracked.

The next patch will optimize IRQ scheduling, so that the CPU is
woken up only for the requested callbacks.

Change-Id: Id9054c44311a7e99aa9996cc9831d72bd460c208
Signed-off-by: Lajos Molnar <molnar@ti.com>
OMAP:DSS: Schedule callback completion irq only when needed

DISPLAYED callback is triggered on VSYNC/FRAMEDONE interrupts.
Only schedule this callback for the interrupts that are requested
and possible.

Change-Id: I03978417a96a1dd1330cd3527b13fe2e433a91bf
Signed-off-by: Lajos Molnar <molnar@ti.com>
dss/manager.c: Fix up previous patch to really work with 2.6.32