sched: Prevent wakeup to enter critical section needlessly

Check the waitqueue task list to be non empty before entering the critical
section. This prevents locking the spin lock needlessly in case the queue
was empty, and therefor also prevent scheduling overhead on a PREEMPT_RT
system.

Signed-off-by: Ivo Sieben <meltedpianoman@gmail.com>
backported from Linux 3.5+ by faux123
timers: Avoid finding cpu for migration of running timers in __mod_timer()

Currently we don't support migration of currently running timers. Current code
flow in __mod_timer() is:
- Find a cpu where we should migrate the timer
- Check if timer is currently running
- If yes, don't migrate.

In this process, the first step is a unnecessary activiy, if the timer is
currently running. This patch tries to avoid it in such cases.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
backported from Linux 3.5+ by faux123
 ARM: always use ARM_UNWIND for thumb2 kernels

Thumb2 kernels cannot be built with frame pointers, but can use the
ARM_UNWIND feature for unwinding instead. This makes sure that all
features that rely on unwinding includeing CONFIG_LATENCYTOP and
FAULT_INJECTION_STACKTRACE_FILTER do not enable frame pointers
when the unwinder is already selected, and we always build with
the unwinder when we want a thumb2 kernel, to make sure we do not
get the frame pointers instead.

A different option would be to redefine the CONFIG_FRAME_POINTERS
option on ARM to mean builing with either frame pointers or
the unwinder, and then select which one to use based on the
CPU architecture or another user option. That would still allow
building thumb2 kernels without the unwinder but would also be
more confusing.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
zram: Fix sparse warnings

Fixes sparse warning:
zram_drv.c:666:6: warning: symbol 'zram_slot_free_notify' was not
declared. Should it be static?

Also, max_zpage_size is now size_t just to be consistent with data-type
of other variables maintaining sizes of various kinds.

Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(cherry picked from commit 2ccbec05ac9917a09aeb2f647667b734b4f02ce1)
slub: When allocating a new slab also prep the first object

We need to branch to the debug code for the first object if we allocate
a new slab otherwise the first object will be marked wrongly as inactive.

Tested-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
(cherry picked from commit 9e577e8b46ab0c38970c0f0cd7eae62e6dffddee)
Fix spinlock types in printk and arch/arm/mm/cache-l2x0
Fix spinlock type in kernel/posix-cpu-timers.c
Wifi : lower operation voltage to 1.8v and firmware startup delay to 60ms
Optimize SLUB
Optimize VFP CFLAGS with neon
ARM : Enable -pipe CFLAGS
lib/sha1: use the git implementation of SHA-1

For ChromiumOS, we use SHA-1 to verify the integrity of the root
filesystem.  The speed of the kernel sha-1 implementation has a major
impact on our boot performance.

To improve boot performance, we investigated using the heavily optimized
sha-1 implementation used in git.  With the git sha-1 implementation, we
see a 11.7% improvement in boot time.

10 reboots, remove slowest/fastest.

Before:

  Mean: 6.58 seconds Stdev: 0.14

After (with git sha-1, this patch):

  Mean: 5.89 seconds Stdev: 0.07

The other cool thing about the git SHA-1 implementation is that it only
needs 64 bytes of stack for the workspace while the original kernel
implementation needed 320 bytes.

Signed-off-by: Mandeep Singh Baines <msb@chromium.org>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Cc: Nicolas Pitre <nico@cam.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove ARM sha1 routines

Since commit 8827a4a6b397b07a341ba7fd36ffb91a7835207d
("lib/sha1: use the git implementation of SHA-1"), the ARM SHA1
routines no longer work. The reason? They depended on the larger
320-byte workspace, and now the sha1 workspace is just 16 words
(64 bytes). So the assembly version would overwrite the stack randomly.

The optimized asm version is also probably slower than the new improved
C version, so there's no reason to keep it around.  At least that was
the case in git, where what appears to be the same assembly language
version was removed two years ago because the optimized C BLK_SHA1 code
was faster.

Reported-and-tested-by: Joachim Eastwood <manabian@gmail.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>