Restrict slave mountspace so Dalvik apps can mount system-wide volumes

Android 4.2 implements multi-user storage using per-process mount
namespaces.  Everything under "/" (the entire filesystem hierarchy) is
marked as a recursive-slave mountspace for all zygote instances.  This
is done so that user-storage sandbox mounts under /storage/emulated are
hidden from other apps and users.

Unfortunately this means that any Dalvik app (actually, any program
whose clone/fork ancestry includes a Dalvik zygote, which is everything
except services spawned directly from init) cannot mount system-wide
volumes. Thus, apps like CifsManager are effectively broken in Android
4.2, since its cifs mounts are only visible to the CifsManager app
itself.  All other apps see empty mountpoints instead of the mounted
volume.  Furthermore, Linux provides no provision for a process to
"escape" a recursive-slave mountspace in versions prior to Linux 3.8
(setns syscall).

Here, we restrict rootfs-slave calls to /storage (and, due to a possible
kernel bug, /mnt/shell/emulated) so that Dalvik apps can mount
system-wide volumes elsewhere (with appropriate permission, as in
earlier versions of Android), while retaining full multi-user storage
compatibility.  It is made available as a kernel-based workaround for
instances where libdvm can not be modified.

This change requires that a tmpfs volume is mounted as /storage in
init.rc. If this volume is unavailable, then we falls back to the
previous behavior of marking the entire filesystem hierarchy as slave.
sync: don't log wait timeouts when timeout = 0
block: fiops io scheduler
msm mip_lgit: stop spamming the log with this debugging info I had
previously added.
sched: Change rq->nr_running to unsigned int

Since there's a PID space limit of 30bits (see
futex.h:FUTEX_TID_MASK) and allocating that many tasks (assuming a
lower bound of 2 pages per task) would still take 8T of memory it
seems reasonable to say that unsigned int is sufficient for
rq->nr_running.

When we do get anywhere near that amount of tasks I suspect other
things would go funny, load-balancer load computations would really
need to be hoisted to 128bit etc.
So save a few bytes and convert rq->nr_running and friends to
unsigned int.

Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link:
http://lkml.kernel.org/n/tip-y3tvyszjdmbibade5bw8zl81@git.kernel.org
sched/nohz: Fix rq->cpu_load[] calculations

While investigating why the load-balancer did funny I found that the
rq->cpu_load[] tables were completely screwy.. a bit more digging
revealed that the updates that got through were missing ticks followed
by a catchup of 2 ticks.

The catchup assumes the cpu was idle during that time (since only nohz
can cause missed ticks and the machine is idle etc..) this means that
esp. the higher indices were significantly lower than they ought to
be.

The reason for this is that its not correct to compare against jiffies
on every jiffy on any other cpu than the cpu that updates jiffies.
This patch cludges around it by only doing the catch-up stuff from
nohz_idle_balance() and doing the regular stuff unconditionally from
the tick.

Link:
http://lkml.kernel.org/n/tip-tp4kj18xdd5aj4vvj0qg55s2@git.kernel.org
sched/nohz: Fix rq->cpu_load calculations some more

Follow up on commit 556061b00 ("sched/nohz: Fix rq->cpu_load[]
calculations") since while that fixed the busy case it regressed the
mostly idle case.

Add a callback from the nohz exit to also age the rq->cpu_load[]
array. This closes the hole where either there was no nohz load
balance pass during the nohz, or there was a 'significant' amount of
idle time between the last nohz balance and the nohz exit.
So we'll update unconditionally from the tick to not insert any
accidental 0 load periods while busy, and we try and catch up from
nohz idle balance and nohz exit. Both these are still prone to missing
a jiffy, but that has always been the case.
sched/nohz: Rewrite and fix load-avg computation -- again

Thanks to Charles Wang for spotting the defects in the current code:
- If we go idle during the sample window -- after sampling, we get a
negative bias because we can negate our own sample.
- If we wake up during the sample window we get a positive bias
because we push the sample to a known active period.
So rewrite the entire nohz load-avg muck once again, now adding
copious documentation to the code.

Reported-and-tested-by: Doug Smythies <dsmythies@telus.net>
Reported-and-tested-by: Charles Wang <muming.wq@gmail.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: stable@kernel.org
Link: http://lkml.kernel.org/r/1340373782.18025.74.camel@twins
[ minor edits ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
sched: Fix race in task_group()

Stefan reported a crash on a kernel before a3e5d1091c1 ("sched:
Don't call task_group() too many times in set_task_rq()"), he
found the reason to be that the multiple task_group()
invocations in set_task_rq() returned different values.
Looking at all that I found a lack of serialization and plain
wrong comments.

The below tries to fix it using an extra pointer which is
updated under the appropriate scheduler locks. Its not pretty,
but I can't really see another way given how all the cgroup
stuff works.

Reported-and-tested-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link:
http://lkml.kernel.org/r/1340364965.18025.71.camel@twins
Signed-off-by: Ingo Molnar <mingo@kernel.org>
sched: Fix nohz_idle_balance()

On tickless systems, one CPU runs load balance for all idle CPUs.
The cpu_load of this CPU is updated before starting the load balance
of each other idle CPUs. We should instead update the cpu_load of
the balance_cpu.

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Venkatesh Pallipadi <venki@google.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Link:
http://lkml.kernel.org/r/1347509486-8688-1-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
sched: Fix load avg vs cpu-hotplug

Rabik and Paul reported two different issues related to the same few
lines of code.

Rabik's issue is that the nr_uninterruptible migration code is wrong in
that he sees artifacts due to this (Rabik please do expand in more
detail).

Paul's issue is that this code as it stands relies on us using
stop_machine() for unplug, we all would like to remove this assumption
so that eventually we can remove this stop_machine() usage altogether.
The only reason we'd have to migrate nr_uninterruptible is so that we
could use for_each_online_cpu() loops in favour of
for_each_possible_cpu() loops, however since nr_uninterruptible() is the
only such loop and its using possible lets not bother at all.
The problem Rabik sees is (probably) caused by the fact that by
migrating nr_uninterruptible we screw rq->calc_load_active for both rqs
involved.

So don't bother with fancy migration schemes (meaning we now have to
keep using for_each_possible_cpu()) and instead fold any nr_active delta
after we migrate all tasks away to make sure we don't have any skewed
nr_active accounting.

[ paulmck: Move call to calc_load_migration to CPU_DEAD to avoid
miscounting noted by Rakib. ]
Reported-by: Rakib Mullick <rakib.mullick@gmail.com>
Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
fs/cifs: squashed updates from upstream 3.4.x
auto_hotplug: rev 4 - let's lean a little more towards performance. 

This includes:

1) Set DEFAULT_SAMPLING_PERIODS back to 10 (from 12)

2) Set DEFAULT_ENABLE_ALL_LOAD_THRESHOLD to (100 * CPUS)

3) Finally came back and fixed "stack the deck" like I had originally
intended after the quick test.

4) Updated to revision to 4.
defconfig: update to cover latest changes for the exp kernel
switch do_fsync() to fget_light()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
ext4: prevent kernel panic in case of uninitialized jinode

In some cases the kernel crash occurs during system suspend/resume:

[ 4095.041351] Unable to handle kernel NULL pointer dereference at
virtual address 00000000 [ 4095.050689] pgd = c0004000
[ 4095.053985] [00000000] *pgd=00000000
[ 4095.058807] Internal error: Oops: 5 [#1] PREEMPT SMP
[ 4095.064483] Modules linked in: wl12xx mac80211 pvrsrvkm_sgx540_120
cfg80211 compat [last unloaded: wl12xx_sdio] [ 4095.064575] CPU: 1   
Tainted: G    B        (3.0.31-01807-gfac16a0 #1) [ 4095.064605] PC is
at jbd2_journal_file_inode+0x38/0x118 [ 4095.064666] LR is at
mpage_da_map_and_submit+0x48c/0x618 [ 4095.064697] pc : [<c01da5a8>]   
lr : [<c01aeac0>]    psr: 60000013 [ 4095.064697] sp : c6e07c80  ip :
c6e07ca0  fp : c6e07c9c [ 4095.064727] r10: 00000001  r9 : c6e06000  r8
: 00000179 [ 4095.064758] r7 : c6e07ca0  r6 : c73b8400  r5 : 00000000 
r4 : c59a7d80 [ 4095.064758] r3 : 00000038  r2 : 00000800  r1 : 00000000
 r0 : c7754fc0 [ 4095.064788] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32
 ISA ARM  Segment kernel [ 4095.064819] Control: 10c5387d  Table:
86cc804a  DAC: 00000015 [ 4095.064849]
[ 4095.064849] PC: 0xc01da528:
[ 4095.064880] a528  0a000003 e3a05000 e1a00005 e24bd020 e89da9f0
e5951010 e3e06000 e14b22dc
.....
[ 4095.070373] 7fe0: c00a48ac 00000013 00000000 c6e07ff8 c00a48ac
c00c0a94 84752f09 60772177 [ 4095.070404] Backtrace:
[ 4095.070465] [<c01da570>] (jbd2_journal_file_inode+0x0/0x118) from
[<c01aeac0>] (mpage_da_map_and_submit+0x48c/0x618) [ 4095.070495] 
r7:c6e07ca0 r6:c6e07d00 r5:c6e07d90 r4:c7754fc0 [ 4095.070556]
[<c01ae634>] (mpage_da_map_and_submit+0x0/0x618) from [<c01af40c>]
(ext4_da_writepages+0x2a4/0x5c8) [ 4095.070617] [<c01af168>]
(ext4_da_writepages+0x0/0x5c8) from [<c0112af4>]
(do_writepages+0x34/0x40) [ 4095.070678] [<c0112ac0>]
(do_writepages+0x0/0x40) from [<c01645a4>]
(writeback_single_inode+0xd4/0x288) [ 4095.070709] [<c01644d0>]
(writeback_single_inode+0x0/0x288) from [<c0164ed4>]
(writeback_sb_inodes+0xb4/0x184) [ 4095.070770] [<c0164e20>]
(writeback_sb_inodes+0x0/0x184) from [<c01655a0>]
(writeback_inodes_wb+0xc4/0x13c) [ 4095.070831] [<c01654dc>]
(writeback_inodes_wb+0x0/0x13c) from [<c01658f0>]
(wb_writeback+0x2d8/0x464) [ 4095.070861] [<c0165618>]
(wb_writeback+0x0/0x464) from [<c0165cb8>] (wb_do_writeback+0x23c/0x2c4)
[ 4095.070922] [<c0165a7c>] (wb_do_writeback+0x0/0x2c4) from
[<c0165df4>] (bdi_writeback_thread+0xb4/0x2dc) [ 4095.070953]
[<c0165d40>] (bdi_writeback_thread+0x0/0x2dc) from [<c00c0b18>]
(kthread+0x90/0x98) [ 4095.071014] [<c00c0a88>] (kthread+0x0/0x98) from
[<c00a48ac>] (do_exit+0x0/0x72c) [ 4095.071044]  r7:00000013 r6:c00a48ac
r5:c00c0a88 r4:c78c7ec4 [ 4095.071105] Code: e89da8f0 e5963000 e3130002
1afffffa (e5913000) [ 4095.071166] ---[ end trace 7fe9f9b727e5cf78 ]---
[ 4095.071197] Kernel panic - not syncing: Fatal exception

The probably reason of such behaviour is an inode opened in READ mode
has been marked as 'dirty' somehow and written back by
ext4_da_writepages. Cause jinode == NULL it could lead to the kernel
panic.

The patch prevents kernel panic and helps to investigate the problem
providing an inode number.

Change-Id: I1d77a011b580db682b8e2d122ef3d5e44e0ce5c7
Signed-off-by: Volodymyr Mieshkov <volodymyr.mieshkov@ti.com>
mako: let's try out a new color scheme
fs/dyn_sync_cntrl: dynamic sync control

The dynamic sync control interface uses Android kernel's unique early
suspend / lat resume interface.

While screen is on, file sync is disabled
when screen is off, a file sync is called to flush all outstanding
writes and restore file sync operation as normal.
defconfig: adding dynamic fsync