Fix gcc-4.9.0 miscompilation of load_balance() in scheduler

commit 2062afb4f804afef61cbe62a30cac9a46e58e067 upstream.

Michel Dänzer and a couple of other people reported inexplicable random
oopses in the scheduler, and the cause turns out to be gcc mis-compiling
the load_balance() function when debugging is enabled.  The gcc bug
apparently goes back to gcc-4.5, but slight optimization changes means
that it now showed up as a problem in 4.9.0 and 4.9.1.

The instruction scheduling problem causes gcc to schedule a spill
operation to before the stack frame has been created, which in turn can
corrupt the spilled value if an interrupt comes in.  There may be other
effects of this bug too, but that's the code generation problem seen in
Michel's case.

This is fixed in current gcc HEAD, but the workaround as suggested by
Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments
when compiling the kernel, which disables the gcc code that causes the
problem.  This can result in slightly worse debug information for
variable accesses, but that is infinitely preferable to actual code
generation problems.

Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows
non-debug builds to verify that the debug build would be identical: we
can do

    export GCC_COMPARE_DEBUG=1

to make gcc internally verify that the result of the build is
independent of the "-g" flag (it will make the compiler build everything
twice, toggling the debug flag, and compare the results).

Without the "-fno-var-tracking-assignments" option, the build would fail
(even with 4.8.3 that didn't show the actual stack frame bug) with a gcc
compare failure.

See also gcc bugzilla:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801

Reported-by: Michel Dänzer <michel@daenzer.net>
Suggested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Jakub Jelinek <jakub@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mm: kmemleak: avoid false negatives on vmalloc'ed objects

commit 7f88f88f83ed609650a01b18572e605ea50cd163 upstream.

Commit 248ac0e1943a ("mm/vmalloc: remove guard page from between vmap
blocks") had the side effect of making vmap_area.va_end member point to
the next vmap_area.va_start.  This was creating an artificial reference
to vmalloc'ed objects and kmemleak was rarely reporting vmalloc() leaks.

This patch marks the vmap_area containing pointers explicitly and
reduces the min ref_count to 2 as vm_struct still contains a reference
to the vmalloc'ed object.  The kmemleak add_scan_area() function has
been improved to allow a SIZE_MAX argument covering the rest of the
object (for simpler calling sites).

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[hq: Backported to 3.4: Adjust context]
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tcp: fix false undo corner cases

[ Upstream commit 6e08d5e3c8236e7484229e46fdf92006e1dd4c49 ]

The undo code assumes that, upon entering loss recovery, TCP
1) always retransmit something
2) the retransmission never fails locally (e.g., qdisc drop)

so undo_marker is set in tcp_enter_recovery() and undo_retrans is
incremented only when tcp_retransmit_skb() is successful.

When the assumption is broken because TCP's cwnd is too small to
retransmit or the retransmit fails locally. The next (DUP)ACK
would incorrectly revert the cwnd and the congestion state in
tcp_try_undo_dsack() or tcp_may_undo(). Subsequent (DUP)ACKs
may enter the recovery state. The sender repeatedly enter and
(incorrectly) exit recovery states if the retransmits continue to
fail locally while receiving (DUP)ACKs.

The fix is to initialize undo_retrans to -1 and start counting on
the first retransmission. Always increment undo_retrans even if the
retransmissions fail locally because they couldn't cause DSACKs to
undo the cwnd reduction.

Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tcp: fix tcp_match_skb_to_sack() for unaligned SACK at end of an skb

[ Upstream commit 2cd0d743b05e87445c54ca124a9916f22f16742e ]

If there is an MSS change (or misbehaving receiver) that causes a SACK
to arrive that covers the end of an skb but is less than one MSS, then
tcp_match_skb_to_sack() was rounding up pkt_len to the full length of
the skb ("Round if necessary..."), then chopping all bytes off the skb
and creating a zero-byte skb in the write queue.

This was visible now because the recently simplified TLP logic in
bef1909ee3ed1c ("tcp: fixing TLP's FIN recovery") could find that 0-byte
skb at the end of the write queue, and now that we do not check that
skb's length we could send it as a TLP probe.

Consider the following example scenario:

 mss: 1000
 skb: seq: 0 end_seq: 4000  len: 4000
 SACK: start_seq: 3999 end_seq: 4000

The tcp_match_skb_to_sack() code will compute:

 in_sack = false
 pkt_len = start_seq - TCP_SKB_CB(skb)->seq = 3999 - 0 = 3999
 new_len = (pkt_len / mss) * mss = (3999/1000)*1000 = 3000
 new_len += mss = 4000

Previously we would find the new_len > skb->len check failing, so we
would fall through and set pkt_len = new_len = 4000 and chop off
pkt_len of 4000 from the 4000-byte skb, leaving a 0-byte segment
afterward in the write queue.

With this new commit, we notice that the new new_len >= skb->len check
succeeds, so that we return without trying to fragment.

Fixes: adb92db857ee ("tcp: Make SACK code to split only at mss boundaries")
Reported-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Ilpo Jarvinen <ilpo.jarvinen@helsinki.fi>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
msm: board-8226: initialize SPM, NCP6335D, FAN53555 and CPR drivers

SPM, NCP6335D and FAN53555 regulators needs to be initialized before CPR
regulator initialization. When cpr-regulator probes, it will try to get a
handle to each of the three regulators: the fan53555-regulator, the
ncp6335d-regulator and spm-regulator devices. CPR will use the first
available handle as its vdd_apc regulator. It is only possible to get a
handle to each of these regulator devices after the driver has probed.
NCP6335D and FAN53555 regulators are clients of QUP I2C, QUP_I2C is a
client of MSM_BUS_FABRIC driver, hence initialize MSM_BUS_FABRIC and
QUP I2C drivers before NCP6335D and FAN53555 regulators.

Change-Id: I57e358b55645c21b058e34a55f039850b71197d4
Signed-off-by: Ke Liu <keliu@codeaurora.org>

michale1900: fix a cherry-pick error

Conflicts:
	arch/arm/mach-msm/board-8226.c
msm: ocmem: Call restore_sec_config() after every power collapse

As the QRIB is enabled, after every power collapse of ocmem, the
QRIB is reset to the maximum security state. Due to this the apps
processor cannot access the ocmem register space.

The restore_sec_config() scm call needs to be called before any
register is accessed after a power collapse to ensure that the
security configuration is restored. The clocks need to be turned
on before every call that is made into TZ to ensure that there
is no power collapse.

CRs-Fixed: 651324, 660089
Change-Id: Ieb6b635142057e219de29e811c93749f6500cec5
Signed-off-by: Neeti Desai <neetid@codeaurora.org>
ARM: dts: msm: add frequency to corner mappings for msm8226v2 and msm8926

Add frequency to corner mappings for turbo fuse corner frequencies in
1.2G and 1.4G speedbin tables which located at msm8226v2 and msm8926
clock-a7 device tree node.
1.2G/1.4G msm8226v2 and msm8926 parts can receive a dynamic quotient
adjustment to scale the CPR target quotient used for each corner, this
ensure these parts receive power saving when running at turbo
frequencies below the maximum possible turbo frequency.

CRs-Fixed: 597721
Change-Id: Ie5992361a79950614d9e2b04a6bfb373e26088a3
Signed-off-by: Fenglin Wu <fenglinw@codeaurora.org>
Signed-off-by: Ke Liu <keliu@codeaurora.org>
iommu: msm: Do not sleep for 10 ms when TLB sync does not complete

TLB sync might take longer than expected to complete and we wait for 10 ms
to recheck. This is causing jitter in some applications. Instead of waiting
too long to check whether TLB sync has completed we use function
readl_tight_poll_timeout to quickly poll the status without incurring sleep
delay.

We also ensure that if we do eventually time out on the TLB sync or iommu
halt we cause a crash to indicate that something has gone wrong.

CRs-fixed: 608971
Change-Id: I6b3e5155ab7aafa80432f95554d25cf0e2b753f9
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
mmc: core: Fix clock frequency transitions during invalid states

eMMC and SD card specifications restrict the usage of a class of
commands while commands in other class are in progress. For example,
during erase operations the SD/eMMC spec. allows only CMD35, CMD36,
CMD38. If clock scaling is enabled and decide to scale up the clocks
it may be possible that CMD19/21 tuning commands are sent in between
erase commands, which is illegal as per specification.

Fix such illegal transactions to the card and also make clock scaling
statistics accountable only for read/write commands instead of time
consuming commands, like CMD38 erase, where transactions are independent
of bus frequency.

Change-Id: Iffba175787837e7f95bde8970f19d0f0f9d7d67d
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>