Linux 3.0.74

commit f97ddf68ad209d6767249bd6852ce053588adfbd
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Apr 16 21:17:25 2013 -0700

    Linux 3.0.74

commit c6c8807630f086872b446cc66752a1835df5e9d7
Author: David Woodhouse <David.Woodhouse@intel.com>
Date:   Tue Oct 9 15:08:10 2012 +0100

    mtd: Disable mtdchar mmap on MMU systems

    commit f5cf8f07423b2677cebebcebc863af77223a4972 upstream.

    This code was broken because it assumed that all MTD devices were map-based.
    Disable it for now, until it can be fixed properly for the next merge window.

    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f0776cdd7c35a4b4ca7b80e6afc4ecd0d26831d7
Author: Hayes Wang <hayeswang@realtek.com>
Date:   Sat Apr 13 12:26:55 2013 +0200

    r8169: fix auto speed down issue

    commit e2409d83434d77874b461b78af6a19cd6e6a1280 upstream.

    It would cause no link after suspending or shutdowning when the
    nic changes the speed to 10M and connects to a link partner which
    forces the speed to 100M.

    Check the link partner ability to determine which speed to set.

    The link speed down code path is not factored in this kernel version.

    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Acked-by: Francois Romieu <romieu@fr.zoreil.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcea984b4ded553023858d55afcf5e782462af1c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Sep 8 12:57:30 2012 -0700

    mtdchar: fix offset overflow detection

    commit 9c603e53d380459fb62fec7cd085acb0b74ac18f upstream.

    Sasha Levin has been running trinity in a KVM tools guest, and was able
    to trigger the BUG_ON() at arch/x86/mm/pat.c:279 (verifying the range of
    the memory type).  The call trace showed that it was mtdchar_mmap() that
    created an invalid remap_pfn_range().

    The problem is that mtdchar_mmap() does various really odd and subtle
    things with the vma page offset etc, and uses the wrong types (and the
    wrong overflow) detection for it.

    For example, the page offset may well be 32-bit on a 32-bit
    architecture, but after shifting it up by PAGE_SHIFT, we need to use a
    potentially 64-bit resource_size_t to correctly hold the full value.

    Also, we need to check that the vma length plus offset doesn't overflow
    before we check that it is smaller than the length of the mtdmap region.

    This fixes things up and tries to make the code a bit easier to read.

    Reported-and-tested-by: Sasha Levin <levinsasha928@gmail.com>
    Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
    Acked-by: Artem Bityutskiy <dedekind1@gmail.com>
    Cc: David Woodhouse <dwmw2@infradead.org>
    Cc: linux-mtd@lists.infradead.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Cc: Brad Spengler <spender@grsecurity.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b1cf3728932d0e6beb0a09812cbc71618939069a
Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date:   Sat Mar 23 09:36:36 2013 -0400

    x86, mm: Patch out arch_flush_lazy_mmu_mode() when running on bare metal

    commit 511ba86e1d386f671084b5d0e6f110bb30b8eeb2 upstream.

    Invoking arch_flush_lazy_mmu_mode() results in calls to
    preempt_enable()/disable() which may have performance impact.

    Since lazy MMU is not used on bare metal we can patch away
    arch_flush_lazy_mmu_mode() so that it is never called in such
    environment.

    [ hpa: the previous patch "Fix vmalloc_fault oops during lazy MMU
      updates" may cause a minor performance regression on
      bare metal.  This patch resolves that performance regression.  It is
      somewhat unclear to me if this is a good -stable candidate. ]

    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Link: http://lkml.kernel.org/r/1364045796-10720-2-git-send-email-konrad.wilk@oracle.com
    Tested-by: Josh Boyer <jwboyer@redhat.com>
    Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Acked-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cfe9f98bf529186fa6365127f089ea69dafb84d5
Author: Samu Kallio <samu.kallio@aberdeencloud.com>
Date:   Sat Mar 23 09:36:35 2013 -0400

    x86, mm, paravirt: Fix vmalloc_fault oops during lazy MMU updates

    commit 1160c2779b826c6f5c08e5cc542de58fd1f667d5 upstream.

    In paravirtualized x86_64 kernels, vmalloc_fault may cause an oops
    when lazy MMU updates are enabled, because set_pgd effects are being
    deferred.

    One instance of this problem is during process mm cleanup with memory
    cgroups enabled. The chain of events is as follows:

    - zap_pte_range enables lazy MMU updates
    - zap_pte_range eventually calls mem_cgroup_charge_statistics,
      which accesses the vmalloc'd mem_cgroup per-cpu stat area
    - vmalloc_fault is triggered which tries to sync the corresponding
      PGD entry with set_pgd, but the update is deferred
    - vmalloc_fault oopses due to a mismatch in the PUD entries

    The OOPs usually looks as so:

    ------------[ cut here ]------------
    kernel BUG at arch/x86/mm/fault.c:396!
    invalid opcode: 0000 [#1] SMP
    .. snip ..
    CPU 1
    Pid: 10866, comm: httpd Not tainted 3.6.10-4.fc18.x86_64 #1
    RIP: e030:[<ffffffff816271bf>]  [<ffffffff816271bf>] vmalloc_fault+0x11f/0x208
    .. snip ..
    Call Trace:
     [<ffffffff81627759>] do_page_fault+0x399/0x4b0
     [<ffffffff81004f4c>] ? xen_mc_extend_args+0xec/0x110
     [<ffffffff81624065>] page_fault+0x25/0x30
     [<ffffffff81184d03>] ? mem_cgroup_charge_statistics.isra.13+0x13/0x50
     [<ffffffff81186f78>] __mem_cgroup_uncharge_common+0xd8/0x350
     [<ffffffff8118aac7>] mem_cgroup_uncharge_page+0x57/0x60
     [<ffffffff8115fbc0>] page_remove_rmap+0xe0/0x150
     [<ffffffff8115311a>] ? vm_normal_page+0x1a/0x80
     [<ffffffff81153e61>] unmap_single_vma+0x531/0x870
     [<ffffffff81154962>] unmap_vmas+0x52/0xa0
     [<ffffffff81007442>] ? pte_mfn_to_pfn+0x72/0x100
     [<ffffffff8115c8f8>] exit_mmap+0x98/0x170
     [<ffffffff810050d9>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
     [<ffffffff81059ce3>] mmput+0x83/0xf0
     [<ffffffff810624c4>] exit_mm+0x104/0x130
     [<ffffffff8106264a>] do_exit+0x15a/0x8c0
     [<ffffffff810630ff>] do_group_exit+0x3f/0xa0
     [<ffffffff81063177>] sys_exit_group+0x17/0x20
     [<ffffffff8162bae9>] system_call_fastpath+0x16/0x1b

    Calling arch_flush_lazy_mmu_mode immediately after set_pgd makes the
    changes visible to the consistency checks.

    RedHat-Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=914737
    Tested-by: Josh Boyer <jwboyer@redhat.com>
    Reported-and-Tested-by: Krishna Raman <kraman@redhat.com>
    Signed-off-by: Samu Kallio <samu.kallio@aberdeencloud.com>
    Link: http://lkml.kernel.org/r/1364045796-10720-1-git-send-email-konrad.wilk@oracle.com
    Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 074ca07eff0e6f5ead1a1c688739c5bf960ca7c4
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Sat Apr 6 10:10:27 2013 +0200

    sched_clock: Prevent 64bit inatomicity on 32bit systems

    commit a1cbcaa9ea87b87a96b9fc465951dcf36e459ca2 upstream.

    The sched_clock_remote() implementation has the following inatomicity
    problem on 32bit systems when accessing the remote scd->clock, which
    is a 64bit value.

    CPU0			CPU1

    sched_clock_local()	sched_clock_remote(CPU0)
    ...
    			remote_clock = scd[CPU0]->clock
    			    read_low32bit(scd[CPU0]->clock)
    cmpxchg64(scd->clock,...)
    			    read_high32bit(scd[CPU0]->clock)

    While the update of scd->clock is using an atomic64 mechanism, the
    readout on the remote cpu is not, which can cause completely bogus
    readouts.

    It is a quite rare problem, because it requires the update to hit the
    narrow race window between the low/high readout and the update must go
    across the 32bit boundary.

    The resulting misbehaviour is, that CPU1 will see the sched_clock on
    CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value
    to this bogus timestamp. This stays that way due to the clamping
    implementation for about 4 seconds until the synchronization with
    CLOCK_MONOTONIC undoes the problem.

    The issue is hard to observe, because it might only result in a less
    accurate SCHED_OTHER timeslicing behaviour. To create observable
    damage on realtime scheduling classes, it is necessary that the bogus
    update of CPU1 sched_clock happens in the context of an realtime
    thread, which then gets charged 4 seconds of RT runtime, which results
    in the RT throttler mechanism to trigger and prevent scheduling of RT
    tasks for a little less than 4 seconds. So this is quite unlikely as
    well.

    The issue was quite hard to decode as the reproduction time is between
    2 days and 3 weeks and intrusive tracing makes it less likely, but the
    following trace recorded with trace_clock=global, which uses
    sched_clock_local(), gave the final hint:

      <idle>-0   0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80
      <idle>-0   0d..30 400269.477151: hrtimer_start:  hrtimer=0xf7061e80 ...
    irq/20-S-587 1d..32 400273.772118: sched_wakeup:   comm= ... target_cpu=0
      <idle>-0   0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80

    What happens is that CPU0 goes idle and invokes
    sched_clock_idle_sleep_event() which invokes sched_clock_local() and
    CPU1 runs a remote wakeup for CPU0 at the same time, which invokes
    sched_remote_clock(). The time jump gets propagated to CPU0 via
    sched_remote_clock() and stays stale on both cores for ~4 seconds.

    There are only two other possibilities, which could cause a stale
    sched clock:

    1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic
       wrong value.

    2) sched_clock() which reads the TSC returns a sporadic wrong value.

    #1 can be excluded because sched_clock would continue to increase for
       one jiffy and then go stale.

    #2 can be excluded because it would not make the clock jump
       forward. It would just result in a stale sched_clock for one jiffy.

    After quite some brain twisting and finding the same pattern on other
    traces, sched_clock_remote() remained the only place which could cause
    such a problem and as explained above it's indeed racy on 32bit
    systems.

    So while on 64bit systems the readout is atomic, we need to verify the
    remote readout on 32bit machines. We need to protect the local->clock
    readout in sched_clock_remote() on 32bit as well because an NMI could
    hit between the low and the high readout, call sched_clock_local() and
    modify local->clock.

    Thanks to Siegfried Wulsch for bearing with my debug requests and
    going through the tedious tasks of running a bunch of reproducer
    systems to generate the debug information which let me decode the
    issue.

    Reported-by: Siegfried Wulsch <Siegfried.Wulsch@rovema.de>
    Acked-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d91fc30b72e90319f1bb35905e284b58b976d6f
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Wed Apr 10 15:00:27 2013 -0700

    target: Fix incorrect fallthrough of ALUA Standby/Offline/Transition CDBs

    commit 30f359a6f9da65a66de8cadf959f0f4a0d498bba upstream.

    This patch fixes a bug where a handful of informational / control CDBs
    that should be allowed during ALUA access state Standby/Offline/Transition
    where incorrectly returning CHECK_CONDITION + ASCQ_04H_ALUA_TG_PT_*.

    This includes INQUIRY + REPORT_LUNS, which would end up preventing LUN
    registration when LUN scanning occured during these ALUA access states.

    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Cc: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44a44be00a8a547855c4265d96b1a42261f26e8a
Author: Huacai Chen <chenhc@lemote.com>
Date:   Sun Apr 7 02:14:14 2013 +0000

    PM / reboot: call syscore_shutdown() after disable_nonboot_cpus()

    commit 6f389a8f1dd22a24f3d9afc2812b30d639e94625 upstream.

    As commit 40dc166c (PM / Core: Introduce struct syscore_ops for core
    subsystems PM) say, syscore_ops operations should be carried with one
    CPU on-line and interrupts disabled. However, after commit f96972f2d
    (kernel/sys.c: call disable_nonboot_cpus() in kernel_restart()),
    syscore_shutdown() is called before disable_nonboot_cpus(), so break
    the rules. We have a MIPS machine with a 8259A PIC, and there is an
    external timer (HPET) linked at 8259A. Since 8259A has been shutdown
    too early (by syscore_shutdown()), disable_nonboot_cpus() runs without
    timer interrupt, so it hangs and reboot fails. This patch call
    syscore_shutdown() a little later (after disable_nonboot_cpus()) to
    avoid reboot failure, this is the same way as poweroff does.

    For consistency, add disable_nonboot_cpus() to kernel_halt().

    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e16fe8625f041b56b2d6866e2bc8abd0284499d0
Author: Namhyung Kim <namhyung.kim@lge.com>
Date:   Mon Apr 1 21:46:23 2013 +0900

    tracing: Fix double free when function profile init failed

    commit 83e03b3fe4daffdebbb42151d5410d730ae50bd1 upstream.

    On the failure path, stat->start and stat->pages will refer same page.
    So it'll attempt to free the same page again and get kernel panic.

    Link: http://lkml.kernel.org/r/1364820385-32027-1-git-send-email-namhyung@kernel.org

    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Namhyung Kim <namhyung.kim@lge.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit da60065417ee775999fd05d2a4ea0c268e4ec30b
Author: Alban Bedel <alban.bedel@avionic-design.de>
Date:   Tue Apr 9 17:13:59 2013 +0200

    ASoC: wm8903: Fix the bypass to HP/LINEOUT when no DAC or ADC is running

    commit f1ca493b0b5e8f42d3b2dc8877860db2983f47b6 upstream.

    The Charge Pump needs the DSP clock to work properly, without it the
    bypass to HP/LINEOUT is not working properly. This requirement is not
    mentioned in the datasheet but has been confirmed by Mark Brown from
    Wolfson.

    Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de>
    Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit facbcede9edd28f9f3290a83fdb6ea4b781ffcd6
Author: Dave Hansen <dave@linux.vnet.ibm.com>
Date:   Wed Jan 30 16:56:16 2013 -0800

    x86-32, mm: Rip out x86_32 NUMA remapping code

    commit f03574f2d5b2d6229dcdf2d322848065f72953c7 upstream.

    [was already included in 3.0, but I missed the patch hunk for
     arch/x86/mm/numa_32.c  - gregkh]

    This code was an optimization for 32-bit NUMA systems.

    It has probably been the cause of a number of subtle bugs over
    the years, although the conditions to excite them would have
    been hard to trigger.  Essentially, we remap part of the kernel
    linear mapping area, and then sometimes part of that area gets
    freed back in to the bootmem allocator.  If those pages get
    used by kernel data structures (say mem_map[] or a dentry),
    there's no big deal.  But, if anyone ever tried to use the
    linear mapping for these pages _and_ cared about their physical
    address, bad things happen.

    For instance, say you passed __GFP_ZERO to the page allocator
    and then happened to get handed one of these pages, it zero the
    remapped page, but it would make a pte to the _old_ page.
    There are probably a hundred other ways that it could screw
    with things.

    We don't need to hang on to performance optimizations for
    these old boxes any more.  All my 32-bit NUMA systems are long
    dead and buried, and I probably had access to more than most
    people.

    This code is causing real things to break today:

    	https://lkml.org/lkml/2013/1/9/376

    I looked in to actually fixing this, but it requires surgery
    to way too much brittle code, as well as stuff like
    per_cpu_ptr_to_phys().

    [ hpa: Cc: this for -stable, since it is a memory corruption issue.
      However, an alternative is to simply mark NUMA as depends BROKEN
      rather than EXPERIMENTAL in the X86_32 subclause... ]

    Link: http://lkml.kernel.org/r/20130131005616.1C79F411@kernel.stglabs.ibm.com
    Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 09d11b951936e52dc1d1513f67d605830f720928
Author: Eldad Zack <eldad@fogrefinery.com>
Date:   Fri Apr 5 20:49:46 2013 +0200

    ALSA: usb-audio: fix endianness bug in snd_nativeinstruments_*

    commit 889d66848b12d891248b03abcb2a42047f8e172a upstream.

    The usb_control_msg() function expects __u16 types and performs
    the endianness conversions by itself.
    However, in three places, a conversion is performed before it is
    handed over to usb_control_msg(), which leads to a double conversion
    (= no conversion):
    * snd_usb_nativeinstruments_boot_quirk()
    * snd_nativeinstruments_control_get()
    * snd_nativeinstruments_control_put()

    Caught by sparse:

    sound/usb/mixer_quirks.c:512:38: warning: incorrect type in argument 6 (different base types)
    sound/usb/mixer_quirks.c:512:38:    expected unsigned short [unsigned] [usertype] index
    sound/usb/mixer_quirks.c:512:38:    got restricted __le16 [usertype] <noident>
    sound/usb/mixer_quirks.c:543:35: warning: incorrect type in argument 5 (different base types)
    sound/usb/mixer_quirks.c:543:35:    expected unsigned short [unsigned] [usertype] value
    sound/usb/mixer_quirks.c:543:35:    got restricted __le16 [usertype] <noident>
    sound/usb/mixer_quirks.c:543:56: warning: incorrect type in argument 6 (different base types)
    sound/usb/mixer_quirks.c:543:56:    expected unsigned short [unsigned] [usertype] index
    sound/usb/mixer_quirks.c:543:56:    got restricted __le16 [usertype] <noident>
    sound/usb/quirks.c:502:35: warning: incorrect type in argument 5 (different base types)
    sound/usb/quirks.c:502:35:    expected unsigned short [unsigned] [usertype] value
    sound/usb/quirks.c:502:35:    got restricted __le16 [usertype] <noident>

    Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
    Acked-by: Daniel Mack <zonque@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
earlysuspend: block userspace until late resume completes

Currently the late_resume function runs in a workqueue that is
triggered when the /sys/power/state is changed when the screen
is turned on. The problem this causes is that userspace sets
/sys/power/state to turn the screen on and after
request_suspend_state() returns userspace expects that the
kernel is ready to receive backlight adjustments, however
the backlight driver may not have finished its late_resume()
function yet, because the late_resume workqueue is still running.
Therefore we can get brightness requests before the backlight
driver late_resume function has completed and during the
resume sequence which can cause for undesired backlight
brightness results.

The solution for this is to have the late_resume functions run
within the context of the user space process that triggered the
screen on event. So that the request_suspend_state('wakeup')
function doesn't return until all the late_resume functions
have been completed. And therefore, userspace doesn't send
backlight (and other) requests to the kernel drivers before
they are all resumed.

Signed-off-by: Joe Swantek <w98568@motorola.com>
cpufreq: interactive: reduce chance of zero time delta on load eval

Reschedule load sampling timer after timestamp of sample start taken,
hold spinlock across entire sequence to avoid preemption.  Avoid the
WARN for zero time delta in the load sampling timer function.

Change-Id: Idc10a756f09141decb6df92669521a1ebf0dbc10
Signed-off-by: Todd Poynor <toddpoynor@google.com>
cpufreq: interactive: Fix uninitialized spinlock

Change-Id: I9959669e0f643ccd2bd1072fae440d8c20f1c9cc
ARM: Fix up vfp exception location in thumb mode

The exception handler in entry-armv.S checks for thumb mode and
correctly determines the exception location and instruction,
but VFP_bounce uses the uncorrected location off the stack.
If the VFP exception occured in Thumb mode, fix up the
exception location on the stack to match the value that would
be returned in ARM mode.

Fixes segfaults in userspace applications running in Thumb mode
caused by a handled VFP exception returning to the middle of the
instruction that triggered the exception.

Change-Id: I02be4c5b546561d9a967a02c1e9eb1de876cff07
Original-author: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Colin Cross <ccross@android.com>
ARM: vfp: Move exception address fixup into vfphw.S

If the PC on the stack is updated in entry-armv.S,
do_undefinstr can get called after the fixup.  do_undefinstr
does its own fixup, and doing both causes the PC to point to
half way through an instruction.

Instead, do the fixup in do_vfp, where only the vfp code
can get called.

Change-Id: I6d966887adc8ed58d88bfe0cb3c0ba29213be488
Signed-off-by: Colin Cross <ccross@android.com>
spade: Correct pm8xxx usage (Juansheng)

"But no idea what the hell difference between pm8xxx and pm8058"

Original commit for vision: https://github.com/Andromadus/htc7x30-3.0/commit/4c0630ac9ce735bee574a93d9b745e2c3b6c99e3
fs/dyn_fsync: check dyn fsync control's active prior to performing fsync ops

Signed-off-by: Andrew Bartholomew <andrewb03@gmail.com>
dynamic filesync: add some cache optimizations

and clean up file format and typos

bump version to 1.1

Signed-off-by: Paul Reioux <reioux@gmail.com>
mutex: Make more scalable by doing less atomic operations

Date	Thu, 4 Apr 2013 10:54:16 -0400

In the __mutex_lock_common() function, an initial entry into
the lock slow path will cause two atomic_xchg instructions to be
issued. Together with the atomic decrement in the fast path, a total
of three atomic read-modify-write instructions will be issued in
rapid succession. This can cause a lot of cache bouncing when many
tasks are trying to acquire the mutex at the same time.

This patch will reduce the number of atomic_xchg instructions used by
checking the counter value first before issuing the instruction. The
atomic_read() function is just a simple memory read. The atomic_xchg()
function, on the other hand, can be up to 2 order of magnitude or even
more in cost when compared with atomic_read(). By using atomic_read()
to check the value first before calling atomic_xchg(), we can avoid a
lot of unnecessary cache coherency traffic. The only downside with this
change is that a task on the slow path will have a tiny bit
less chance of getting the mutex when competing with another task
in the fast path.

The same is true for the atomic_cmpxchg() function in the
mutex-spin-on-owner loop. So an atomic_read() is also performed before
calling atomic_cmpxchg().

The mutex locking and unlocking code for the x86 architecture can allow
any negative number to be used in the mutex count to indicate that some
tasks are waiting for the mutex. I am not so sure if that is the case
for the other architectures. So the default is to avoid atomic_xchg()
if the count has already been set to -1. For x86, the check is modified
to include all negative numbers to cover a larger case.

The following table shows the scalability data on an 8-node 80-core
Westmere box with a 3.7.10 kernel. The numactl command is used to
restrict the running of the high_systime workloads to 1/2/4/8 nodes
with hyperthreading on and off.

+-----------------+------------------+------------------+----------+
|  Configuration  | Mean Transaction | Mean Transaction | % Change |
|		  |  Rate w/o patch  | Rate with patch  |	   |
+-----------------+------------------------------------------------+
|		  |              User Range 1100 - 2000		   |
+-----------------+------------------------------------------------+
| 8 nodes, HT on  |      36980       |      148590      | +301.8%  |
| 8 nodes, HT off |      42799       |      145011      | +238.8%  |
| 4 nodes, HT on  |	 61318       |      118445      |  +51.1%  |
| 4 nodes, HT off |     158481       |      158592      |   +0.1%  |
| 2 nodes, HT on  |     180602       |      173967      |   -3.7%  |
| 2 nodes, HT off |     198409       |      198073      |   -0.2%  |
| 1 node , HT on  |     149042       |      147671      |   -0.9%  |
| 1 node , HT off |     126036       |      126533      |   +0.4%  |
+-----------------+------------------------------------------------+
|		  |              User Range 200 - 1000		   |
+-----------------+------------------------------------------------+
| 8 nodes, HT on  |      41525       |      122349      | +194.6%  |
| 8 nodes, HT off |      49866       |      124032      | +148.7%  |
| 4 nodes, HT on  |	 66409       |      106984      |  +61.1%  |
| 4 nodes, HT off |     119880       |      130508      |   +8.9%  |
| 2 nodes, HT on  |     138003       |      133948      |   -2.9%  |
| 2 nodes, HT off |     132792       |      131997      |   -0.6%  |
| 1 node , HT on  |     116593       |      115859      |   -0.6%  |
| 1 node , HT off |     104499       |      104597      |   +0.1%  |
+-----------------+------------------+------------------+----------+
AIM7 benchmark run has a pretty large run-to-run variance due to random
nature of the subtests executed. So a difference of less than +-5%
may not be really significant.

This patch improves high_systime workload performance at 4 nodes
and up by maintaining transaction rates without significant drop-off
at high node count.  The patch has practically no impact on 1 and 2
nodes system.

The table below shows the percentage time (as reported by perf
record -a -s -g) spent on the __mutex_lock_slowpath() function by
the high_systime workload at 1500 users for 2/4/8-node configurations
with hyperthreading off.

+---------------+-----------------+------------------+---------+
| Configuration | %Time w/o patch | %Time with patch | %Change |
+---------------+-----------------+------------------+---------+
|    8 nodes    |      65.34%     |      0.69%       |  -99%   |
|    4 nodes    |       8.70%	  |      1.02%	     |  -88%   |
|    2 nodes    |       0.41%     |      0.32%       |  -22%   |
+---------------+-----------------+------------------+---------+
It is obvious that the dramatic performance improvement at 8
nodes was due to the drastic cut in the time spent within the
__mutex_lock_slowpath() function.

The table below show the improvements in other AIM7 workloads (at 8
nodes, hyperthreading off).

+--------------+---------------+----------------+-----------------+
|   Workload   | mean % change | mean % change  | mean % change   |
|              | 10-100 users  | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests     |     +0.6%     |   +104.2%      |   +185.9%       |
| five_sec     |     +1.9%     |     +0.9%      |     +0.9%       |
| fserver      |     +1.4%     |     -7.7%      |     +5.1%       |
| new_fserver  |     -0.5%     |     +3.2%      |     +3.1%       |
| shared       |    +13.1%     |   +146.1%      |   +181.5%       |
| short        |     +7.4%     |     +5.0%      |     +4.2%       |
+--------------+---------------+----------------+-----------------+
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
mutex: restrict mutex spinning to only one task per mutex

Date	Thu, 4 Apr 2013 10:54:17 -0400

The current mutex spinning code allow multiple tasks to spin on a
single mutex concurrently. There are two major problems with this
approach:

 1. This is not very energy efficient as the spinning tasks are not
    doing useful work. The spinning tasks may also block other more
    important or useful tasks from running as preemption is disabled.
    Only one of the spinners will get the mutex at any time. The
    other spinners will have to wait for much longer to get it.

 2. The mutex data structure on x86-64 should be 32 bytes. The spinning
    code spin on lock->owner which, in most cases, should be in the same
    64-byte cache line as the lock->wait_lock spinlock. As a result,
    the mutex spinners are contending the same cacheline with other
    CPUs trying to get the spinlock leading to increased time spent
    on the spinlock as well as on the mutex spinning.

These problems are worse on system with large number of CPUs. One way
to reduce the effect of these two problems is to allow only one task
to be spinning on a mutex at any time.

This patch adds a new spinner field in the mutex.h to limit the
number of spinner to only one task. That will increase the size of
the mutex by 8 bytes in a 64-bit environment (4 bytes in a 32-bit
environment).

The AIM7 benchmarks were run on 3.7.10 derived kernels to show the
performance changes with this patch on a 8-socket 80-core system
with hyperthreading off.  The table below shows the mean % change
in performance over a range of users for some AIM7 workloads with
just the less atomic operation patch (patch 1) vs the less atomic
operation patch plus this one (patches 1+2).

+--------------+-----------------+-----------------+-----------------+
|   Workload   | mean % change   | mean % change   | mean % change   |
|              | 10-100 users    | 200-1000 users  | 1100-2000 users |
+--------------+-----------------+-----------------+-----------------+
| alltests     |     -0.2%       |     -3.8%       |    -4.2%        |
| five_sec     |     -0.6%       |     -2.0%       |    -2.4%        |
| fserver      |     +2.2%       |    +16.2%       |    +2.2%        |
| high_systime |     -0.3%       |     -4.3%       |    -3.0%        |
| new_fserver  |     +3.9%       |    +16.0%       |    +9.5%        |
| shared       |     -1.7%       |     -5.0%       |    -4.0%        |
| short        |     -7.7%       |     +0.2%       |    +1.3%        |
+--------------+-----------------+-----------------+-----------------+
It can be seen that this patch improves performance for the fserver and
new_fserver workloads while suffering some slight drop in performance
for the other workloads.

Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
mutex: dynamically disable mutex spinning at high load
Date	Thu, 4 Apr 2013 10:54:18 -0400

The Linux mutex code has a MUTEX_SPIN_ON_OWNER configuration
option that was enabled by default in major distributions like Red
Hat. Allowing threads waiting on mutex to spin while the mutex owner
is running will theoretically reduce latency on the acquisition of
mutex at the expense of energy efficiency as the spinning threads
are doing no useful work.

This is not a problem on a lightly loaded system where the CPU may
be idle anyway. On a highly loaded system, the spinning tasks may be
blocking other tasks from running even if they have higher priority
because the spinning was done with preemption disabled.

This patch will disable mutex spinning if the current load is high
enough. The load is considered high if there are 2 or more active tasks
waiting to run on the current CPU. If there is only one task waiting,
it will check the average load at the past minute (calc_load_tasks).
If it is more than double the number of active CPUs, the load is
considered high too.  This is a rather simple metric that does not
incur that much additional overhead.

The AIM7 benchmarks were run on 3.7.10 derived kernels to show the
performance changes with this patch on a 8-socket 80-core system
with hyperthreading off.  The table below shows the mean % change
in performance over a range of users for some AIM7 workloads with
just the less atomic operation patch (patch 1) vs the less atomic
operation patch plus this one (patches 1+3).

+--------------+-----------------+-----------------+-----------------+
|   Workload   | mean % change   | mean % change   | mean % change   |
|              | 10-100 users    | 200-1000 users  | 1100-2000 users |
+--------------+-----------------+-----------------+-----------------+
| alltests     |      0.0%       |     -0.1%       |    +5.0%        |
| five_sec     |     +1.5%       |     +1.3%       |    +1.3%        |
| fserver      |     +1.5%       |    +25.4%       |    +9.6%        |
| high_systime |     +0.1%       |      0.0%       |    +0.8%        |
| new_fserver  |     +0.2%       |    +11.9%       |   +14.1%        |
| shared       |     -1.2%       |     +0.3%       |    +1.8%        |
| short        |     +6.4%       |     +2.5%       |    +3.0%        |
+--------------+-----------------+-----------------+-----------------+
It can be seen that this patch provides some big performance
improvement for the fserver and new_fserver workloads while is still
generally positive for the other AIM7 workloads.

Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
modified for tuna kernel from LKML

Signed-off-by: Paul Reioux <reioux@gmail.com>
lcdc_spade_wvga: remove unused variable color_enhancement
usb: core: hub: remove unused variable hcd
mmc: core: remove unused variables to and rem
mmc: core: remove unused function mmc_do_erase
fs: nfs4proc: fix bad format
pm8xxx-gpio: fix missing return
Revert "cpufreq: ondemand: Fix kernel warning in cpufreq_governor_dbs"

This reverts commit a3fb017421e7941c3f967eb461f9f7e9f65b2926.
Revert "ext3: add support for .read_iter and .write_iter"

This reverts commit 7f2abedd667245e65d96ae4656e1699a9946b0ab.