n_tty: Fix n_tty_write crash when echoing in raw mode

The tty atomic_write_lock does not provide an exclusion guarantee for
the tty driver if the termios settings are LECHO & !OPOST.  And since
it is unexpected and not allowed to call TTY buffer helpers like
tty_insert_flip_string concurrently, this may lead to crashes when
concurrect writers call pty_write. In that case the following two
writers:
* the ECHOing from a workqueue and
* pty_write from the process
race and can overflow the corresponding TTY buffer like follows.

If we look into tty_insert_flip_string_fixed_flag, there is:
  int space = __tty_buffer_request_room(port, goal, flags);
  struct tty_buffer *tb = port->buf.tail;
  ...
  memcpy(char_buf_ptr(tb, tb->used), chars, space);
  ...
  tb->used += space;

so the race of the two can result in something like this:
              A                                B
__tty_buffer_request_room
                                  __tty_buffer_request_room
memcpy(buf(tb->used), ...)
tb->used += space;
                                  memcpy(buf(tb->used), ...) ->BOOM

B's memcpy is past the tty_buffer due to the previous A's tb->used
increment.

Since the N_TTY line discipline input processing can output
concurrently with a tty write, obtain the N_TTY ldisc output_lock to
serialize echo output with normal tty writes.  This ensures the tty
buffer helper tty_insert_flip_string is not called concurrently and
everything is fine.

Note that this is nicely reproducible by an ordinary user using
forkpty and some setup around that (raw termios + ECHO). And it is
present in kernels at least after commit
d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to
use the normal buffering logic) in 2.6.31-rc3.

js: add more info to the commit log
js: switch to bool
js: lock unconditionally
js: lock only the tty->ops->write call

References: CVE-2014-0196
Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.4: output_lock is a member of struct tty_struct]

Change-Id: I9530780b811e0ce9b0216e943822210b3131a8d6
cpufreq: Update to zzmoove 0.9-beta2

Changelog:

- support for setting a default settings profile at governor start without the need of using the tuneable 'profile_number'
  a default profile can be set with the already available macro 'DEF_PROFILE_NUMBER' check zzmoove_profiles.h for details about
  which profile numbers are possible. this functionality was only half baken in previous versions, now any given profile will be really
  applied when the governor starts. the value '0' (=profile name 'none') in 'DEF_PROFILE_NUMBER' disables this profile hardcoding and
  that's also the default in the source. u still can (with or without enabling a default profile in the macro) as usual use the tuneable
  'profile_number' to switch to a desired profile via sysfs at any later time after governor has started
- added 'blocking' of sysfs in all tuneables during apply of a settings profile to avoid a possible and unwanted overwriting/double
  setting of tuneables mostly in combination with tuning apps where the tuneable apply order isn't influenceable
- added tuneable 'profile_list' for printing out a list of all profiles which are available in the profile header file
- fixed non setting of 'scaling_block_force_down' tuneable when applying profiles
- some documentation added and a little bit of source cleaning
su: update su to version 2.00
earysuspend: speedup late resume (faster wakeup of the  device)

credits to Yank555.lu

Thanx to _2bad4u_ for the hint and dsc-team's repo I got the code from (https://github.com/dsc-team/dsc-team-kernel-project)
slub.c: little tweak for performance improvements
lowmemorykiller: Lower default debug_level
sched_fair: Reduce latencies
writeback: Fix occasional slow sync

In case when system contains no dirty pages, wakeup_flusher_threads()
will submit WB_SYNC_NONE writeback for 0 pages so wb_writeback() exits
immediately without doing anything. Thus sync(1) will write all the
dirty inodes from a WB_SYNC_ALL writeback pass which is slow.

Fix the problem by using get_nr_dirty_pages() in
wakeup_flusher_threads() instead of calculating number of dirty pages
manually. That function also takes number of dirty inodes into account.
mach-exynos: Don't compile unused 4210 objects on 4x12
mach-midas: Slightly increase thermal throttling temperatures and frequency for step1
mali: update driver from r3p2 rel3 to r3p2 rel4 + set older mali api for compatibility reasons

credits to JustArchi
boeffla_defconfig: enable speedup_keyresume
Release tag: 6.0-beta3
vmscan: Fix zRam
Boeffla ramfs: Enable zRam control again in Boeffla-Config
Release tag: 6.0-beta4