Added patch

Signed-off-by: klozz <xxx.reptar.rawrr.xxx@gmail.com>
commit 91f7c8cbc8fd1a4ef69005347e4bc30016cd60ec
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Jul 31 14:56:22 2014 -0700

    Linux 3.4.101

commit 7e2e611849fa3786431f86411346ecb70c3f4283
Author: Catalin Marinas <catalin.marinas@arm.com>
Date:   Tue Nov 12 15:07:45 2013 -0800

    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>

commit b06b5c6204bdc7c571feedb6b16188ba62feb9a6
Author: Xi Wang <xi.wang@gmail.com>
Date:   Thu May 31 16:26:04 2012 -0700

    introduce SIZE_MAX

    commit a3860c1c5dd1137db23d7786d284939c5761d517 upstream.

    ULONG_MAX is often used to check for integer overflow when calculating
    allocation size.  While ULONG_MAX happens to work on most systems, there
    is no guarantee that `size_t' must be the same size as `long'.

    This patch introduces SIZE_MAX, the maximum value of `size_t', to improve
    portability and readability for allocation size validation.

    Signed-off-by: Xi Wang <xi.wang@gmail.com>
    Acked-by: Alex Elder <elder@dreamhost.com>
    Cc: David Airlie <airlied@linux.ie>
    Cc: Pekka Enberg <penberg@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Qiang Huang <h.huangqiang@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 883ea134ae75eb03c9f08553a81957a808cee96b
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Mon Jun 23 15:29:40 2014 +0200

    s390/ptrace: fix PSW mask check

    commit dab6cf55f81a6e16b8147aed9a843e1691dcd318 upstream.

    The PSW mask check of the PTRACE_POKEUSR_AREA command is incorrect.
    The PSW_MASK_USER define contains the PSW_MASK_ASC bits, the ptrace
    interface accepts all combinations for the address-space-control
    bits. To protect the kernel space the PSW mask check in ptrace needs
    to reject the address-space-control bit combination for home space.

    Fixes CVE-2014-3534

    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5c662d1f7ced868472bdf3abb4215202c0e467f
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat Jul 26 14:52:01 2014 -0700

    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>

commit 97f5dabba097a693e3e79d235b549db5de701f0f
Author: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date:   Wed Jul 23 14:00:19 2014 -0700

    mm: hugetlb: fix copy_hugetlb_page_range()

    commit 0253d634e0803a8376a0d88efee0bf523d8673f9 upstream.

    Commit 4a705fef9862 ("hugetlb: fix copy_hugetlb_page_range() to handle
    migration/hwpoisoned entry") changed the order of
    huge_ptep_set_wrprotect() and huge_ptep_get(), which leads to breakage
    in some workloads like hugepage-backed heap allocation via libhugetlbfs.
    This patch fixes it.

    The test program for the problem is shown below:

      $ cat heap.c
      #include <unistd.h>
      #include <stdlib.h>
      #include <string.h>

      #define HPS 0x200000

      int main() {
      	int i;
      	char *p = malloc(HPS);
      	memset(p, '1', HPS);
      	for (i = 0; i < 5; i++) {
      		if (!fork()) {
      			memset(p, '2', HPS);
      			p = malloc(HPS);
      			memset(p, '3', HPS);
      			free(p);
      			return 0;
      		}
      	}
      	sleep(1);
      	free(p);
      	return 0;
      }

      $ export HUGETLB_MORECORE=yes ; export HUGETLB_NO_PREFAULT= ; hugectl --heap ./heap

    Fixes 4a705fef9862 ("hugetlb: fix copy_hugetlb_page_range() to handle
    migration/hwpoisoned entry"), so is applicable to -stable kernels which
    include it.

    Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Reported-by: Guillaume Morin <guillaume@morinfr.org>
    Suggested-by: Guillaume Morin <guillaume@morinfr.org>
    Acked-by: Hugh Dickins <hughd@google.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4aedd4b0545222fed4bb7318fc144025eda8e119
Author: Sven Wegener <sven.wegener@stealer.net>
Date:   Tue Jul 22 10:26:06 2014 +0200

    x86_32, entry: Store badsys error code in %eax

    commit 8142b215501f8b291a108a202b3a053a265b03dd upstream.

    Commit 554086d ("x86_32, entry: Do syscall exit work on badsys
    (CVE-2014-4508)") introduced a regression in the x86_32 syscall entry
    code, resulting in syscall() not returning proper errors for undefined
    syscalls on CPUs supporting the sysenter feature.

    The following code:

    > int result = syscall(666);
    > printf("result=%d errno=%d error=%s\n", result, errno, strerror(errno));

    results in:

    > result=666 errno=0 error=Success

    Obviously, the syscall return value is the called syscall number, but it
    should have been an ENOSYS error. When run under ptrace it behaves
    correctly, which makes it hard to debug in the wild:

    > result=-1 errno=38 error=Function not implemented

    The %eax register is the return value register. For debugging via ptrace
    the syscall entry code stores the complete register context on the
    stack. The badsys handlers only store the ENOSYS error code in the
    ptrace register set and do not set %eax like a regular syscall handler
    would. The old resume_userspace call chain contains code that clobbers
    %eax and it restores %eax from the ptrace registers afterwards. The same
    goes for the ptrace-enabled call chain. When ptrace is not used, the
    syscall return value is the passed-in syscall number from the untouched
    %eax register.

    Use %eax as the return value register in syscall_badsys and
    sysenter_badsys, like a real syscall handler does, and have the caller
    push the value onto the stack for ptrace access.

    Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
    Link: http://lkml.kernel.org/r/alpine.LNX.2.11.1407221022380.31021@titan.int.lan.stealer.net
    Reviewed-and-tested-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46005527d70f86028b688ff48d1bde86313dcf78
Author: Romain Degez <romain.degez@gmail.com>
Date:   Fri Jul 11 18:08:13 2014 +0200

    ahci: add support for the Promise FastTrak TX8660 SATA HBA (ahci mode)

    commit b32bfc06aefab61acc872dec3222624e6cd867ed upstream.

    Add support of the Promise FastTrak TX8660 SATA HBA in ahci mode by
    registering the board in the ahci_pci_tbl[].

    Note: this HBA also provide a hardware RAID mode when activated in
    BIOS but specific drivers from the manufacturer are required in this
    case.

    Signed-off-by: Romain Degez <romain.degez@gmail.com>
    Tested-by: Romain Degez <romain.degez@gmail.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80cd492c4ed16b106113c60a004171e858aff88a
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Jul 23 09:05:27 2014 -0400

    libata: introduce ata_host->n_tags to avoid oops on SAS controllers

    commit 1a112d10f03e83fb3a2fdc4c9165865dec8a3ca6 upstream.

    1871ee134b73 ("libata: support the ata host which implements a queue
    depth less than 32") directly used ata_port->scsi_host->can_queue from
    ata_qc_new() to determine the number of tags supported by the host;
    unfortunately, SAS controllers doing SATA don't initialize ->scsi_host
    leading to the following oops.

     BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
     IP: [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
     PGD 0
     Oops: 0002 [#1] SMP
     Modules linked in: isci libsas scsi_transport_sas mgag200 drm_kms_helper ttm
     CPU: 1 PID: 518 Comm: udevd Not tainted 3.16.0-rc6+ #62
     Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.02.0002.122320131210 12/23/2013
     task: ffff880c1a00b280 ti: ffff88061a000000 task.ti: ffff88061a000000
     RIP: 0010:[<ffffffff814e0618>]  [<ffffffff814e0618>] ata_qc_new_init+0x188/0x1b0
     RSP: 0018:ffff88061a003ae8  EFLAGS: 00010012
     RAX: 0000000000000001 RBX: ffff88000241ca80 RCX: 00000000000000fa
     RDX: 0000000000000020 RSI: 0000000000000020 RDI: ffff8806194aa298
     RBP: ffff88061a003ae8 R08: ffff8806194a8000 R09: 0000000000000000
     R10: 0000000000000000 R11: ffff88000241ca80 R12: ffff88061ad58200
     R13: ffff8806194aa298 R14: ffffffff814e67a0 R15: ffff8806194a8000
     FS:  00007f3ad7fe3840(0000) GS:ffff880627620000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000058 CR3: 000000061a118000 CR4: 00000000001407e0
     Stack:
      ffff88061a003b20 ffffffff814e96e1 ffff88000241ca80 ffff88061ad58200
      ffff8800b6bf6000 ffff880c1c988000 ffff880619903850 ffff88061a003b68
      ffffffffa0056ce1 ffff88061a003b48 0000000013d6e6f8 ffff88000241ca80
     Call Trace:
      [<ffffffff814e96e1>] ata_sas_queuecmd+0xa1/0x430
      [<ffffffffa0056ce1>] sas_queuecommand+0x191/0x220 [libsas]
      [<ffffffff8149afee>] scsi_dispatch_cmd+0x10e/0x300 [<ffffffff814a3bc5>] scsi_request_fn+0x2f5/0x550
      [<ffffffff81317613>] __blk_run_queue+0x33/0x40
      [<ffffffff8131781a>] queue_unplugged+0x2a/0x90
      [<ffffffff8131ceb4>] blk_flush_plug_list+0x1b4/0x210
      [<ffffffff8131d274>] blk_finish_plug+0x14/0x50
      [<ffffffff8117eaa8>] __do_page_cache_readahead+0x198/0x1f0
      [<ffffffff8117ee21>] force_page_cache_readahead+0x31/0x50
      [<ffffffff8117ee7e>] page_cache_sync_readahead+0x3e/0x50
      [<ffffffff81172ac6>] generic_file_read_iter+0x496/0x5a0
      [<ffffffff81219897>] blkdev_read_iter+0x37/0x40
      [<ffffffff811e307e>] new_sync_read+0x7e/0xb0
      [<ffffffff811e3734>] vfs_read+0x94/0x170
      [<ffffffff811e43c6>] SyS_read+0x46/0xb0
      [<ffffffff811e33d1>] ? SyS_lseek+0x91/0xb0
      [<ffffffff8171ee29>] system_call_fastpath+0x16/0x1b
     Code: 00 00 00 88 50 29 83 7f 08 01 19 d2 83 e2 f0 83 ea 50 88 50 34 c6 81 1d 02 00 00 40 c6 81 17 02 00 00 00 5d c3 66 0f 1f 44 00 00 <89> 14 25 58 00 00 00

    Fix it by introducing ata_host->n_tags which is initialized to
    ATA_MAX_QUEUE - 1 in ata_host_init() for SAS controllers and set to
    scsi_host_template->can_queue in ata_host_register() for !SAS ones.
    As SAS hosts are never registered, this will give them the same
    ATA_MAX_QUEUE - 1 as before.  Note that we can't use
    scsi_host->can_queue directly for SAS hosts anyway as they can go
    higher than the libata maximum.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
    Reported-by: Jesse Brandeburg <jesse.brandeburg@gmail.com>
    Reported-by: Peter Hurley <peter@hurleysoftware.com>
    Reported-by: Peter Zijlstra <peterz@infradead.org>
    Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
    Fixes: 1871ee134b73 ("libata: support the ata host which implements a queue depth less than 32")
    Cc: Kevin Hao <haokexin@gmail.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6f0844c44da00772a8ab116fe8bb8549517a8859
Author: Kevin Hao <haokexin@gmail.com>
Date:   Sat Jul 12 12:08:24 2014 +0800

    libata: support the ata host which implements a queue depth less than 32

    commit 1871ee134b73fb4cadab75752a7152ed2813c751 upstream.

    The sata on fsl mpc8315e is broken after the commit 8a4aeec8d2d6
    ("libata/ahci: accommodate tag ordered controllers"). The reason is
    that the ata controller on this SoC only implement a queue depth of
    16. When issuing the commands in tag order, all the commands in tag
    16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
    malfunction. It makes no senses to use a 32 queue in software while
    the hardware has less queue depth. So consider the queue depth
    implemented by the hardware when requesting a command tag.

    Fixes: 8a4aeec8d2d6 ("libata/ahci: accommodate tag ordered controllers")
    Signed-off-by: Kevin Hao <haokexin@gmail.com>
    Acked-by: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 696acd9dc0b30f29ed9732b237c4670034e91863
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue Jul 8 12:25:28 2014 +0200

    block: don't assume last put of shared tags is for the host

    commit d45b3279a5a2252cafcd665bbf2db8c9b31ef783 upstream.

    There is no inherent reason why the last put of a tag structure must be
    the one for the Scsi_Host, as device model objects can be held for
    arbitrary periods.  Merge blk_free_tags and __blk_free_tags into a single
    funtion that just release a references and get rid of the BUG() when the
    host reference wasn't the last.

    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: klozz <xxx.reptar.rawrr.xxx@gmail.com>