Linux 3.0.61

commit 214dfbe8f312326911434eee3ef521e3b78e1399
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Jan 27 20:52:34 2013 -0800

    Linux 3.0.61

commit be6ee99fe4380b6b1a50e15c4bdb3cdd719620fc
Author: Shuah Khan <shuah.khan@hp.com>
Date:   Thu Oct 25 10:22:32 2012 -0600

    ioat: Fix DMA memory sync direction correct flag

    commit ac4989874af56435c308bdde9ad9c837a26f8b23 upstream.

    ioat does DMA memory sync with DMA_TO_DEVICE direction on a buffer allocated
    for DMA_FROM_DEVICE dma, resulting in the following warning from dma debug.
    Fixed the dma_sync_single_for_device() call to use the correct direction.

    [  226.288947] WARNING: at lib/dma-debug.c:990 check_sync+0x132/0x550()
    [  226.288948] Hardware name: ProLiant DL380p Gen8
    [  226.288951] ioatdma 0000:00:04.0: DMA-API: device driver syncs DMA memory with different direction [device address=0x00000000ffff7000] [size=4096 bytes] [mapped with DMA_FROM_DEVICE] [synced with DMA_TO_DEVICE]
    [  226.288953] Modules linked in: iTCO_wdt(+) sb_edac(+) ioatdma(+) microcode serio_raw pcspkr edac_core hpwdt(+) iTCO_vendor_support hpilo(+) dca acpi_power_meter ata_generic pata_acpi sd_mod crc_t10dif ata_piix libata hpsa tg3 netxen_nic(+) sunrpc dm_mirror dm_region_hash dm_log dm_mod
    [  226.288967] Pid: 1055, comm: work_for_cpu Tainted: G        W    3.3.0-0.20.el7.x86_64 #1
    [  226.288968] Call Trace:
    [  226.288974]  [<ffffffff810644cf>] warn_slowpath_common+0x7f/0xc0
    [  226.288977]  [<ffffffff810645c6>] warn_slowpath_fmt+0x46/0x50
    [  226.288980]  [<ffffffff81345502>] check_sync+0x132/0x550
    [  226.288983]  [<ffffffff81345c9f>] debug_dma_sync_single_for_device+0x3f/0x50
    [  226.288988]  [<ffffffff81661002>] ? wait_for_common+0x72/0x180
    [  226.288995]  [<ffffffffa019590f>] ioat_xor_val_self_test+0x3e5/0x832 [ioatdma]
    [  226.288999]  [<ffffffff811a5739>] ? kfree+0x259/0x270
    [  226.289004]  [<ffffffffa0195d77>] ioat3_dma_self_test+0x1b/0x20 [ioatdma]
    [  226.289008]  [<ffffffffa01952c3>] ioat_probe+0x2f8/0x348 [ioatdma]
    [  226.289011]  [<ffffffffa0195f51>] ioat3_dma_probe+0x1d5/0x2aa [ioatdma]
    [  226.289016]  [<ffffffffa0194d12>] ioat_pci_probe+0x139/0x17c [ioatdma]
    [  226.289020]  [<ffffffff81354b8c>] local_pci_probe+0x5c/0xd0
    [  226.289023]  [<ffffffff81083e50>] ? destroy_work_on_stack+0x20/0x20
    [  226.289025]  [<ffffffff81083e68>] do_work_for_cpu+0x18/0x30
    [  226.289029]  [<ffffffff8108d997>] kthread+0xb7/0xc0
    [  226.289033]  [<ffffffff8166cef4>] kernel_thread_helper+0x4/0x10
    [  226.289036]  [<ffffffff81662d20>] ? _raw_spin_unlock_irq+0x30/0x50
    [  226.289038]  [<ffffffff81663234>] ? retint_restore_args+0x13/0x13
    [  226.289041]  [<ffffffff8108d8e0>] ? kthread_worker_fn+0x1a0/0x1a0
    [  226.289044]  [<ffffffff8166cef0>] ? gs_change+0x13/0x13
    [  226.289045] ---[ end trace e1618afc7a606089 ]---
    [  226.289047] Mapped at:
    [  226.289048]  [<ffffffff81345307>] debug_dma_map_page+0x87/0x150
    [  226.289050]  [<ffffffffa019653c>] dma_map_page.constprop.18+0x70/0xb34 [ioatdma]
    [  226.289054]  [<ffffffffa0195702>] ioat_xor_val_self_test+0x1d8/0x832 [ioatdma]
    [  226.289058]  [<ffffffffa0195d77>] ioat3_dma_self_test+0x1b/0x20 [ioatdma]
    [  226.289061]  [<ffffffffa01952c3>] ioat_probe+0x2f8/0x348 [ioatdma]

    Signed-off-by: Shuah Khan <shuah.khan@hp.com>
    Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a94e7cf81096fab2a8625e1ffaae0853a80e77b2
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Wed Jan 16 23:40:07 2013 +0100

    ACPI / cpuidle: Fix NULL pointer issues when cpuidle is disabled

    commit b88a634a903d9670aa5f2f785aa890628ce0dece upstream.

    If cpuidle is disabled, that means that:

    	per_cpu(acpi_cpuidle_device, pr->id)

    is set to NULL as the acpi_processor_power_init ends up failing at

    	 retval = cpuidle_register_driver(&acpi_idle_driver)

    (in acpi_processor_power_init) and never sets the per_cpu idle
    device.  So when acpi_processor_hotplug on CPU online notification
    tries to reference said device it crashes:

    cpu 3 spinlock event irq 62
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
    IP: [<ffffffff81381013>] acpi_processor_setup_cpuidle_cx+0x3f/0x105
    PGD a259b067 PUD ab38b067 PMD 0
    Oops: 0002 [#1] SMP
    odules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c nouveau mxm_wmi wmi radeon ttm sg sr_mod sd_mod cdrom ata_generic ata_piix libata crc32c_intel scsi_mod atl1c i915 fbcon tileblit font bitblit softcursor drm_kms_helper video xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs xen_privcmd mperf
    CPU 1
    Pid: 3047, comm: bash Not tainted 3.8.0-rc3upstream-00250-g165c029 #1 MSI MS-7680/H61M-P23 (MS-7680)
    RIP: e030:[<ffffffff81381013>]  [<ffffffff81381013>] acpi_processor_setup_cpuidle_cx+0x3f/0x105
    RSP: e02b:ffff88001742dca8  EFLAGS: 00010202
    RAX: 0000000000010be9 RBX: ffff8800a0a61800 RCX: ffff880105380000
    RDX: 0000000000000003 RSI: 0000000000000200 RDI: ffff8800a0a61800
    RBP: ffff88001742dce8 R08: ffffffff81812360 R09: 0000000000000200
    R10: aaaaaaaaaaaaaaaa R11: 0000000000000001 R12: ffff8800a0a61800
    R13: 00000000ffffff01 R14: 0000000000000000 R15: ffffffff81a907a0
    FS:  00007fd6942f7700(0000) GS:ffff880105280000(0000) knlGS:0000000000000000
    CS:  e033 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000004 CR3: 00000000a6773000 CR4: 0000000000042660
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process bash (pid: 3047, threadinfo ffff88001742c000, task ffff880017944000)
    Stack:
     0000000000000150 ffff880100f59e00 ffff88001742dcd8 ffff8800a0a61800
     0000000000000000 00000000ffffff01 0000000000000000 ffffffff81a907a0
     ffff88001742dd18 ffffffff813815b1 ffff88001742dd08 ffffffff810ae336
    Call Trace:
     [<ffffffff813815b1>] acpi_processor_hotplug+0x7c/0x9f
     [<ffffffff810ae336>] ? schedule_delayed_work_on+0x16/0x20
     [<ffffffff8137ee8f>] acpi_cpu_soft_notify+0x90/0xca
     [<ffffffff8166023d>] notifier_call_chain+0x4d/0x70
     [<ffffffff810bc369>] __raw_notifier_call_chain+0x9/0x10
     [<ffffffff81094a4b>] __cpu_notify+0x1b/0x30
     [<ffffffff81652cf7>] _cpu_up+0x103/0x14b
     [<ffffffff81652e18>] cpu_up+0xd9/0xec
     [<ffffffff8164a254>] store_online+0x94/0xd0
     [<ffffffff814122fb>] dev_attr_store+0x1b/0x20
     [<ffffffff81216404>] sysfs_write_file+0xf4/0x170

    This patch fixes it.

    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 06cce029daed3ce1d98164b921bb3a826ad2a12a
Author: Robin Holt <holt@sgi.com>
Date:   Thu Dec 20 15:05:50 2012 -0800

    SGI-XP: handle non-fatal traps

    commit 891348ca0f66206f1dc0e30d63757e3df1ae2d15 upstream.

    We found a user code which was raising a divide-by-zero trap.  That trap
    would lead to XPC connections between system-partitions being torn down
    due to the die_chain notifier callouts it received.

    This also revealed a different issue where multiple callers into
    xpc_die_deactivate() would all attempt to do the disconnect in parallel
    which would sometimes lock up but often overwhelm the console on very
    large machines as each would print at least one line of output at the
    end of the deactivate.

    I reviewed all the users of the die_chain notifier and changed the code
    to ignore the notifier callouts for reasons which will not actually lead
    to a system to continue on to call die().

    [akpm@linux-foundation.org: fix ia64]
    Signed-off-by: Robin Holt <holt@sgi.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@elte.hu>
    Cc: <stable@vger.kernel.org>
    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 b6d3beb65f210873ef9a64a9fd204796e122da7c
Author: Kees Cook <keescook@chromium.org>
Date:   Thu Jan 24 14:14:20 2013 -0600

    x86: Use enum instead of literals for trap values [PARTIAL]

    [Based on commit c94082656dac74257f63e91f78d5d458ac781fa5 upstream, only
    taking the traps.h portion.]

    The traps are referred to by their numbers and it can be difficult to
    understand them while reading the code without context. This patch adds
    enumeration of the trap numbers and replaces the numbers with the correct
    enum for x86.

    Signed-off-by: Kees Cook <keescook@chromium.org>
    Link: http://lkml.kernel.org/r/20120310000710.GA32667@www.outflux.net
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Robin Holt <holt@sgi.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d87f5a89f5e2d2ce9e3c1b21bd2debe2130cbc90
Author: Alan Cox <alan@linux.intel.com>
Date:   Tue Sep 4 16:25:25 2012 +0100

    ahci: Add identifiers for ASM106x devices

    commit 7b4f6ecacb14f384adc1a5a67ad95eb082c02bd1 upstream.

    They don't always appear as AHCI class devices but instead as IDE class.

    Based on an initial patch by Hiroaki Nito

    Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42804
    Signed-off-by: Alan Cox <alan@linux.intel.com>
    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
    Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b250e45d7e464c63428170f1b3d2e1e0bd7a6468
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Dec 14 23:38:28 2012 +0100

    drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled

    commit 4283908ef7f11a72c3b80dd4cf026f1a86429f82 upstream.

    Quoting from Bspec, 3D_CHICKEN1, bit 10

    This bit needs to be set always to "1", Project: DevSNB "

    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 231788ba2f713b751b8c46f6ac257b7811df7476
Author: Bart Westgeest <bart@elbrys.com>
Date:   Mon Jan 23 10:55:46 2012 -0500

    staging: usbip: changed function return type to void

    commit ac2b41acfa3efe4650102067a99251587a806d70 upstream.

    The function usbip_pad_iso never returns anything but 0 (success).

    Signed-off-by: Bart Westgeest <bart@elbrys.com>
    Cc: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9d332c77f72e7d9643116e53ae0c1e2bebd3156
Author: Jiri Slaby <jirislaby@gmail.com>
Date:   Sun Jun 5 22:51:49 2011 +0200

    serial: 8250, increase PASS_LIMIT

    commit e7328ae1848966181a7ac47e8ae6cddbd2cf55f3 upstream.

    With virtual machines like qemu, it's pretty common to see "too much
    work for irq4" messages nowadays. This happens when a bunch of output
    is printed on the emulated serial console. This is caused by too low
    PASS_LIMIT. When ISR loops more than the limit, it spits the message.

    I've been using a kernel with doubled the limit and I couldn't see no
    problems. Maybe it's time to get rid of the message now?

    Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
    Cc: Alan Cox <alan@linux.intel.com>
    Cc: Ram Gupta <ram.gupta5@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6aa749906b92eaec6ca0469f90f35de26044d90
Author: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date:   Thu Dec 20 15:05:14 2012 -0800

    drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists

    commit 9f9c9cbb60576a1518d0bf93fb8e499cffccf377 upstream.

    The right dmi version is in SMBIOS if it's zero in DMI region

    This issue was originally found from an oracle bug.
    One customer noticed system UUID doesn't match between dmidecode & uek2.

     - HP ProLiant BL460c G6 :
       # cat /sys/devices/virtual/dmi/id/product_uuid
       00000000-0000-4C48-3031-4D5030333531
       # dmidecode | grep -i uuid
       UUID: 00000000-0000-484C-3031-4D5030333531

    From SMBIOS 2.6 on, spec use little-endian encoding for UUID other than
    network byte order.

    So we need to get dmi version to distinguish.  If version is 0.0, the
    real version is taken from the SMBIOS version.  This is part of original
    kernel comment in code.

    [akpm@linux-foundation.org: checkpatch fixes]
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Cc: Feng Jin <joe.jin@oracle.com>
    Cc: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88e10f8813d2f214178adc5f8ac62e4531bd6fdc
Author: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Date:   Thu Dec 20 15:05:13 2012 -0800

    drivers/firmware/dmi_scan.c: check dmi version when get system uuid

    commit f1d8e614d74b09531b9a85e812485340f3df7b1c upstream.

    As of version 2.6 of the SMBIOS specification, the first 3 fields of the
    UUID are supposed to be little-endian encoded.

    Also a minor fix to match variable meaning and mute checkpatch.pl

    [akpm@linux-foundation.org: tweak code comment]
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
    Cc: Feng Jin <joe.jin@oracle.com>
    Cc: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Abdallah Chatila <abdallah.chatila@ericsson.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0aa31f182374b77a4b704585605ee35a642826cf
Author: Joel D. Diaz <joeldiaz@us.ibm.com>
Date:   Wed Oct 10 10:36:11 2012 +0200

    SCSI: sd: Reshuffle init_sd to avoid crash

    commit afd5e34b2bb34881d3a789e62486814a49b47faa upstream.

    scsi_register_driver will register a prep_fn() function, which
    in turn migh need to use the sd_cdp_pool for DIF.
    Which hasn't been initialised at this point, leading to
    a crash. So reshuffle the init_sd() and exit_sd() paths
    to have the driver registered last.

    Signed-off-by: Joel D. Diaz <joeldiaz@us.ibm.com>
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>
    Cc: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27b2a263fa42cbad0fb33da2de30e4bbc380c43f
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Jan 22 11:37:35 2013 -0500

    USB: UHCI: fix IRQ race during initialization

    commit 0f815a0a700bc10547449bde6c106051a035a1b9 upstream.

    This patch (as1644) fixes a race that occurs during startup in
    uhci-hcd.  If the IRQ line is shared with other devices, it's possible
    for the handler routine to be called before the data structures are
    fully initialized.

    The problem is fixed by adding a check to the IRQ handler routine.  If
    the initialization hasn't finished yet, the routine will return
    immediately.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-by: Don Zickus <dzickus@redhat.com>
    Tested-by: "Huang, Adrian (ISS Linux TW)" <adrian.huang@hp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ef3319d2624e24085982336facc71b414c134f4a
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue Nov 27 14:09:40 2012 +0000

    PCI: Allow pcie_aspm=force even when FADT indicates it is unsupported

    commit 9e16721498b0c3d3ebfa0b503c63d35c0a4c0642 upstream.

    Right now using pcie_aspm=force will not enable ASPM if the FADT indicates
    ASPM is unsupported.  However, the semantics of force should probably allow
    for this, especially as they did before 3c076351c4 ("PCI: Rework ASPM
    disable code")

    This patch just skips the clearing of any ASPM setup that the firmware has
    carried out on this bus if pcie_aspm=force is being used.

    Reference: http://bugs.launchpad.net/bugs/962038
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1085a87765acabfdf55577e4c844a6d4609a6eb2
Author: Steven Rostedt <srostedt@redhat.com>
Date:   Fri Dec 14 09:48:15 2012 -0500

    ftrace: Be first to run code modification on modules

    commit c1bf08ac26e92122faab9f6c32ea8aba94612dae upstream.

    If some other kernel subsystem has a module notifier, and adds a kprobe
    to a ftrace mcount point (now that kprobes work on ftrace points),
    when the ftrace notifier runs it will fail and disable ftrace, as well
    as kprobes that are attached to ftrace points.

    Here's the error:

     WARNING: at kernel/trace/ftrace.c:1618 ftrace_bug+0x239/0x280()
     Hardware name: Bochs
     Modules linked in: fat(+) stap_56d28a51b3fe546293ca0700b10bcb29__8059(F) nfsv4 auth_rpcgss nfs dns_resolver fscache xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack lockd sunrpc ppdev parport_pc parport microcode virtio_net i2c_piix4 drm_kms_helper ttm drm i2c_core [last unloaded: bid_shared]
     Pid: 8068, comm: modprobe Tainted: GF            3.7.0-0.rc8.git0.1.fc19.x86_64 #1
     Call Trace:
      [<ffffffff8105e70f>] warn_slowpath_common+0x7f/0xc0
      [<ffffffff81134106>] ? __probe_kernel_read+0x46/0x70
      [<ffffffffa0180000>] ? 0xffffffffa017ffff
      [<ffffffffa0180000>] ? 0xffffffffa017ffff
      [<ffffffff8105e76a>] warn_slowpath_null+0x1a/0x20
      [<ffffffff810fd189>] ftrace_bug+0x239/0x280
      [<ffffffff810fd626>] ftrace_process_locs+0x376/0x520
      [<ffffffff810fefb7>] ftrace_module_notify+0x47/0x50
      [<ffffffff8163912d>] notifier_call_chain+0x4d/0x70
      [<ffffffff810882f8>] __blocking_notifier_call_chain+0x58/0x80
      [<ffffffff81088336>] blocking_notifier_call_chain+0x16/0x20
      [<ffffffff810c2a23>] sys_init_module+0x73/0x220
      [<ffffffff8163d719>] system_call_fastpath+0x16/0x1b
     ---[ end trace 9ef46351e53bbf80 ]---
     ftrace failed to modify [<ffffffffa0180000>] init_once+0x0/0x20 [fat]
      actual: cc:bb:d2:4b:e1

    A kprobe was added to the init_once() function in the fat module on load.
    But this happened before ftrace could have touched the code. As ftrace
    didn't run yet, the kprobe system had no idea it was a ftrace point and
    simply added a breakpoint to the code (0xcc in the cc:bb:d2:4b:e1).

    Then when ftrace went to modify the location from a call to mcount/fentry
    into a nop, it didn't see a call op, but instead it saw the breakpoint op
    and not knowing what to do with it, ftrace shut itself down.

    The solution is to simply give the ftrace module notifier the max priority.
    This should have been done regardless, as the core code ftrace modification
    also happens very early on in boot up. This makes the module modification
    closer to core modification.

    Link: http://lkml.kernel.org/r/20130107140333.593683061@goodmis.org

    Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
    Reported-by: Frank Ch. Eigler <fche@redhat.com>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

commit 4a0bc1774dfad467dc5e844516712fcd3fe03899
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jan 15 16:17:54 2013 +0000

    drm/i915: Invalidate the relocation presumed_offsets along the slow path

    commit 262b6d363fcff16359c93bd58c297f961f6e6273 upstream.

    In the slow path, we are forced to copy the relocations prior to
    acquiring the struct mutex in order to handle pagefaults. We forgo
    copying the new offsets back into the relocation entries in order to
    prevent a recursive locking bug should we trigger a pagefault whilst
    holding the mutex for the reservations of the execbuffer. Therefore, we
    need to reset the presumed_offsets just in case the objects are rebound
    back into their old locations after relocating for this exexbuffer - if
    that were to happen we would assume the relocations were valid and leave
    the actual pointers to the kernels dangling, instant hang.

    Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4
    Author: Chris Wilson <chris@chris-wilson.co.uk>
    Date:   Sun Nov 21 22:07:12 2010 +0000

        drm/i915: Handle pagefaults in execbuffer user relocations

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Daniel Vetter <daniel.vetter@fwll.ch>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>