gpu: ion: Add source of allocated page

It might be useful for higher levels in the call chain to know whether a
page came from the page pool or from the buddy allocator. If a page came
from the page pool we know that the page has been zeroed already and we
do not have to do that again.

CRs-fixed: 660049
Change-Id: I849591a56e5af8a5bc4340bff70f23e3702e62fb
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[nabrah@codeaurora.org: changes were manually merged from
 drivers/staging/android/ion]
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>
gpu: ion: Optimize zeroing when allocating from system heap

Currently when allocating from system heap each page is individually
mapped and zero'ed in the page pool code. Under high memory pressure when
we allocate a lot of small pages this becomes a bottleneck. Instead,
do the zeroing in one fell swoop at the end of allocating all the pages
but only for the pages that are not already zero'ed and sync'ed (pages
coming from the page pool).

Test results
------------
Time recorded for allocating 20 x 19MB ION buffers from System heap with
forced 4K page allocations (all pages allocated was order-0) right after
boot to Android homescreen using performance kernel configuration.

Before change (non-cached allocations):
Run 1: 768ms
Run 2: 752ms
Run 3: 759ms

Before change (cached allocations):
Run 1: 726ms
Run 2: 769ms
Run 3: 645ms

After change (cached allocations):
Run 1: 262ms
Run 2: 249ms
Run 3: 310ms

After change (non-cached allocations):
Run 1: 275ms
Run 2: 234ms
Run 3: 259ms

Time recorded for allocating 20 x 19MB ION buffers from System heap (with no
forced page size) right after boot to Android homescreen using
performance kernel configuration. Run 1 is taken right after boot while
run 2 and 3 are subsequent runs without reboot between.

Before change (non-cached allocations):
Run 1: 181ms
Run 2: 1ms
Run 3: 1ms

Before change (cached allocations):
Run 1: 220ms
Run 2: 1ms
Run 3: 2ms

After change (non-cached allocations):
Run 1: 166ms
Run 2: 1ms
Run 3: 1ms

After change (cached allocations):
Run 1: 170ms
Run 2: 1ms
Run 3: 3ms

CRs-fixed: 660049
Change-Id: I8dcfdb4adb8d5f4480768f951523fa5c64db87b1
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[nabrah@codeaurora.org: changes manually merged from
 drivers/staging/android/ion. In ion_system_heap.c, in function
 ion_system_heap_allocate, the call to 'list_first_entry_or_null'
 is replaced with  'list_first_entry' and 'list_empty' as
 'list_first_entry_or_null is not supported in 3.4 kernel branch]
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>
gpu: ion: Reduce allocation time from system heap

If we are under heavy memory pressure the shrinker might be running on
the system heap. This causes contention with the page pool lock when we
try to allocate from system heap. To ensure that allocations aren't
slowed down by having to wait for the page pool mutex we will just try
to get the mutex. If we are unsuccessful we just bypass the pool
altogether.

CRs-fixed: 687475
Change-Id: I3e92e3081355a8528438e41e74b716a2b49a3891
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[nabrah@codeaurora.org: changes were manually merged from
 drivers/staging/android/ion]
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>
gpu-ion: hack to get kernel built
vsprintf: ignore %n again

This ignores %n in printf again, as was originally documented.
Implementing %n poses a greater security risk than utility, so it should
stay ignored.  To help anyone attempting to use %n, a warning will be
emitted if it is encountered.

Based on an earlier patch by Joe Perches.

Because %n was designed to write to pointers on the stack, it has been
frequently used as an attack vector when bugs are found that leak
user-controlled strings into functions that ultimately process format
strings.  While this class of bug can still be turned into an
information leak, removing %n eliminates the common method of elevating
such a bug into an arbitrary kernel memory writing primitive,
significantly reducing the danger of this class of bug.

For seq_file users that need to know the length of a written string for
padding, please see seq_setwidth() and seq_pad() instead.

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Joe Perches <joe@perches.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: 9196436ab2f713b823a2ba2024cb69f40b2f54a5
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
CRs-fixed: 665291
Change-Id: Id191acaf66e3c395df92b0a77331269b525e3cad
Signed-off-by: David Brown <davidb@codeaurora.org>
seq_file: introduce seq_setwidth() and seq_pad()

There are several users who want to know bytes written by seq_*() for
alignment purpose.  Currently they are using %n format for knowing it
because seq_*() returns 0 on success.

This patch introduces seq_setwidth() and seq_pad() for allowing them to
align without using %n format.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Joe Perches <joe@perches.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Git-commit: 839cc2a94cc3665bafe32203c2f095f4dd470a80)
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
CRs-fixed: 665291
Change-Id: I727d9af5ed320d717295c9d0f82c88623fb181c1
Signed-off-by: David Brown <davidb@codeaurora.org>
seq_file: remove %n usage from seq_file users
ASoC: wcd9xxx: Don't enable micbias if headset is removed
mmc: core: Fix null pointer dereference due to race conditions
msm: camera2: cpp: Fix to correct pointer in copy_to_user call