remove "+"

Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
Nuke DEBUG_KERNEL
Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
ext4: speed up truncate/unlink by not using bforget() unless needed
Do not iterate over data blocks scanning for bh's to forget as they're
never exist. This improves time taken by unlink / truncate syscall.
Tested by continuously truncating file that is being written by dd.
Another test is rm -rf of linux tree while tar unpacks it. With
ordered data mode condition unlikely(!tbh) was always met in
ext4_free_blocks. With journal data mode tbh was found only few times,
so optimisation is also possible.

Unlinking fallocated 60G file after doing sync && echo 3 >
/proc/sys/vm/drop_caches && time rm --help

X86 before (linux 3.6-rc4):
real    0m2.710s
user    0m0.000s
sys     0m1.530s

X86 after:
real    0m0.644s
user    0m0.003s
sys     0m0.060s

MIPS before (linux 2.6.37):
real    0m 4.93s
user    0m 0.00s
sys     0m 4.61s

MIPS after:
real    0m 0.16s
user    0m 0.00s
sys     0m 0.06s

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Andrey Sidorov <qrxd43@motorola.com>
Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
writeback: fix occasional slow sync && fix race that cause writeback hung
1) 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, even though there are dirty inodes in
the system.  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.

Signed-off-by: Jan Kara <jack@suse.cz>
Reported-by: Paul Taysom <taysom@chromium.org>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

2) fix race that cause writeback hung

There is a race between mark inode dirty and writeback thread, see the
following scenario.  In this case, writeback thread will not run though
there is dirty_io.

__mark_inode_dirty()                                          bdi_writeback_workfn()
	...                                                       	...
	spin_lock(&inode->i_lock);
	...
	if (bdi_cap_writeback_dirty(bdi)) {
	    <<< assume wb has dirty_io, so wakeup_bdi is false.
	    <<< the following inode_dirty also have wakeup_bdi false.
	    if (!wb_has_dirty_io(&bdi->wb))
		    wakeup_bdi = true;
	}
	spin_unlock(&inode->i_lock);
	                                                            <<< assume last dirty_io is removed here.
	                                                            pages_written = wb_do_writeback(wb);
	                                                            ...
	                                                            <<< work_list empty and wb has no dirty_io,
	                                                            <<< delayed_work will not be queued.
	                                                            if (!list_empty(&bdi->work_list) ||
	                                                                (wb_has_dirty_io(wb) && dirty_writeback_interval))
	                                                                queue_delayed_work(bdi_wq, &wb->dwork,
	                                                                    msecs_to_jiffies(dirty_writeback_interval * 10));
	spin_lock(&bdi->wb.list_lock);
	inode->dirtied_when = jiffies;
	<<< new dirty_io is added.
	list_move(&inode->i_wb_list, &bdi->wb.b_dirty);
	spin_unlock(&bdi->wb.list_lock);

	<<< though there is dirty_io, but wakeup_bdi is false,
	<<< so writeback thread will not be waked up and
	<<< the new dirty_io will not be flushed.
	if (wakeup_bdi)
	    bdi_wakeup_thread_delayed(bdi);

Writeback will run until there is a new flush work queued.  This may cause
a lot of dirty pages stay in memory for a long time.

Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Squashed:
Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
ARM: LoUIS cache maintenance API

 ARM v7 architecture introduced the concept of cache levels and related
 coherency requirements. New processors like A7 and A15 embed an
 L2 unified cache controller that becomes part of the cache level
 hierarchy. Some operations in the kernel like cpu_suspend and __cpu_disable
 does not require a flush of the entire cache hierarchy to DRAM but just the
 cache levels belonging to the Level of Unification Inner Shareable (LoUIS),
 which in most of ARM v7 systems correspond to L1.
 The current cache flushing API used in cpu_suspend and __cpu_disable,
 flush_cache_all(), ends up flushing the whole cache hierarchy since for
 v7 it cleans and invalidates all cache levels up to Level of Coherency
 (LoC) which cripples system performance when used in hot paths like hotplug
 and cpuidle.

 Therefore a new kernel cache maintenance API must be added to the
 cpu_cache_fns structure of pointers to cope with latest ARM system requirements.
 This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.

 This function cleans and invalidates all data cache levels up to the
 level of unification inner shareable (LoUIS) and invalidates the instruction
 cache.

 The cpu_cache_fns struct reflects this change by adding a new function pointer
 that is initialized by arch specific assembly files.

 By default, all existing ARM archs do not instantiate any cache LoUIS function
 pointer, and flush_dcache_louis just falls back to flush_kern_all.

 Reviewed-by: Santosh Shilimkar <santosh.shilimkar at ti.com>
 Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>

Initial adaptation for msm8974

Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
Signed-off-by: Anonymous <kernelhackx@gmx.com>
Remove unused lines
fs/exec.c:531: undefined reference to `flush_kernel_dcache_page'
fs/exec.c:549: undefined reference to `flush_kernel_dcache_page'

lib/scatterlist.c:423: undefined reference to `flush_kernel_dcache_page'

Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
block: Add I/O schedulers
Add SIO, FIOPS and BFQ 3.4.0-v6r2

Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
block: small cleanup to iosched
Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
FS: import F2FS

Signed-off-by: Paul Reioux <reioux@gmail.com>
defconfig: F2FS Support
Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
lib/memcopy: use glibc version

the kernel's memcpy and memmove is very inefficient. But the glibc version is
quite fast, in some cases it is 10 times faster than the kernel version. So I
introduce some memory copy macros and functions of the glibc to improve the
kernel version's performance.

The strategy of the memory functions is:
1. Copy bytes until the destination pointer is aligned.
2. Copy words in unrolled loops.  If the source and destination are not
   aligned in the same way, use word memory operations, but shift and merge
   two read words before writing.
3. Copy the few remaining bytes.

Signed-off-by: Miao Xie <miaox*******>
Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
lib/string: use glibc version

the performance of memcpy and memmove of the general version is very
inefficient, this patch improved them.

Signed-off-by: Miao Xie <miaox*******>
Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
lib/int_sqrt.c: optimize square root algorithm

Optimize the current version of the shift-and-subtract (hardware)
algorithm, described by John von Newmann[1] and Guy L Steele.

Iterating 1,000,000 times, perf shows for the current version:

 Performance counter stats for './sqrt-curr' (10 runs):

         27.170996 task-clock                #    0.979 CPUs utilized            ( +-  3.19% )
                 3 context-switches          #    0.103 K/sec                    ( +-  4.76% )
                 0 cpu-migrations            #    0.004 K/sec                    ( +-100.00% )
               104 page-faults               #    0.004 M/sec                    ( +-  0.16% )
        64,921,199 cycles                    #    2.389 GHz                      ( +-  0.03% )
        28,967,789 stalled-cycles-frontend   #   44.62% frontend cycles idle     ( +-  0.18% )
   <not supported> stalled-cycles-backend
       104,502,623 instructions              #    1.61  insns per cycle
                                             #    0.28  stalled cycles per insn  ( +-  0.00% )
        34,088,368 branches                  # 1254.587 M/sec                    ( +-  0.00% )
             4,901 branch-misses             #    0.01% of all branches          ( +-  1.32% )

       0.027763015 seconds time elapsed                                          ( +-  3.22% )

And for the new version:

Performance counter stats for './sqrt-new' (10 runs):

          0.496869 task-clock                #    0.519 CPUs utilized            ( +-  2.38% )
                 0 context-switches          #    0.000 K/sec
                 0 cpu-migrations            #    0.403 K/sec                    ( +-100.00% )
               104 page-faults               #    0.209 M/sec                    ( +-  0.15% )
           590,760 cycles                    #    1.189 GHz                      ( +-  2.35% )
           395,053 stalled-cycles-frontend   #   66.87% frontend cycles idle     ( +-  3.67% )
   <not supported> stalled-cycles-backend
           398,963 instructions              #    0.68  insns per cycle
                                             #    0.99  stalled cycles per insn  ( +-  0.39% )
            70,228 branches                  #  141.341 M/sec                    ( +-  0.36% )
             3,364 branch-misses             #    4.79% of all branches          ( +-  5.45% )

       0.000957440 seconds time elapsed                                          ( +-  2.42% )

Furthermore, this saves space in instruction text:

   text    data     bss     dec     hex filename
    111       0       0     111      6f lib/int_sqrt-baseline.o
     89       0       0      89      59 lib/int_sqrt.o

[1] http://en.wikipedia.org/wiki/First_Draft_of_a_Report_on_the_EDVAC

Signed-off-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
Reviewed-by: Jonathan Gonzalez <jgonzlez@linets.cl>
Tested-by: Jonathan Gonzalez <jgonzlez@linets.cl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
SELinux: Fix memory leak upon loading policy
commit 8ed8146 upstream.

Hello.

I got below leak with linux-3.10.0-54.0.1.el7.x86_64 .

[  681.903890] kmemleak: 5538 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

Below is a patch, but I don't know whether we need special handing for undoing
ebitmap_set_bit() call.
----------
>>From fe97527 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Mon, 6 Jan 2014 16:30:21 +0900
Subject: SELinux: Fix memory leak upon loading policy

Commit 2463c26 "SELinux: put name based create rules in a hashtable" did not
check return value from hashtab_insert() in filename_trans_read(). It leaks
memory if hashtab_insert() returns error.

  unreferenced object 0xffff88005c9160d0 (size 8):
    comm "systemd", pid 1, jiffies 4294688674 (age 235.265s)
    hex dump (first 8 bytes):
      57 0b 00 00 6b 6b 6b a5                          W...kkk.
    backtrace:
      [<ffffffff816604ae>] kmemleak_alloc+0x4e/0xb0
      [<ffffffff811cba5e>] kmem_cache_alloc_trace+0x12e/0x360
      [<ffffffff812aec5d>] policydb_read+0xd1d/0xf70
      [<ffffffff812b345c>] security_load_policy+0x6c/0x500
      [<ffffffff812a623c>] sel_write_load+0xac/0x750
      [<ffffffff811eb680>] vfs_write+0xc0/0x1f0
      [<ffffffff811ec08c>] SyS_write+0x4c/0xa0
      [<ffffffff81690419>] system_call_fastpath+0x16/0x1b
      [<ffffffffffffffff>] 0xffffffffffffffff

However, we should not return EEXIST error to the caller, or the systemd will
show below message and the boot sequence freezes.

  systemd[1]: Failed to load SELinux policy. Freezing.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
msm: clock-krait-8974: User voltage control for msm-cpufreq device

Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
defconfig: enable voltage control
Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
sched: set mc_power_savings=2
this feature packs tasks together and try to bind them to cpu0, which in theory will let cpu1 idle longer, thus improving battery life.

Info: http://elinux.org/images/1/1d/Comparing_Power_Saving_Techniques_For_Multicore_ARM_Platforms.pdf

Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
arm: add auto hotplug and limit boot frequency.
This adds Will Tisdale's auto_hotplug V.220, also limited boot frequency to 1958Mhz for a stable kernel.
Still experimental and will slowly observe and make changes on it as it goes.

Initial Adaptation for the Samsung Galaxy S5

Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
Enable auto hotplug and BFQ scheduler
Made small changes to auto_hotplug.c to prevent MISMATCH errors.

CHANGES:
added __cpuinit to current changed files.

Signed-off-by: Jean Francis Dominique S. Mabalot <jfdsmabalot@redhat.com>
block: sysfs: allow non superusers to change i/o scheduler