Skip to content
Commits on Jan 28, 2013
  1. @gregkh

    Linux 3.4.28

    gregkh committed
  2. @gregkh

    ioat: Fix DMA memory sync direction correct flag

    Shuah Khan committed with gregkh
    commit ac49898 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 <>
    Signed-off-by: Vinod Koul <>
    Signed-off-by: Greg Kroah-Hartman <>
  3. @gregkh

    ACPI / processor: Get power info before updating the C-states

    Thomas Schlichter committed with gregkh
    commit f427e5f upstream.
    acpi_processor_get_power_info() has to be called before
    acpi_processor_setup_cpuidle_states() to have the latest
    information available. This fixes the missing C-state information
    after AC-->DC transition.
    Signed-off-by: Thomas Schlichter <>
    Signed-off-by: Rafael J. Wysocki <>
    Signed-off-by: Greg Kroah-Hartman <>
  4. @gregkh

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

    Konrad Rzeszutek Wilk committed with gregkh
    commit b88a634 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)
     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 <>
    Signed-off-by: Rafael J. Wysocki <>
    Signed-off-by: Greg Kroah-Hartman <>
  5. @danvet @gregkh

    drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled

    danvet committed with gregkh
    commit 4283908 upstream.
    Quoting from Bspec, 3D_CHICKEN1, bit 10
    This bit needs to be set always to "1", Project: DevSNB "
    Reviewed-by: Rodrigo Vivi <>
    Signed-off-by: Daniel Vetter <>
    Signed-off-by: Abdallah Chatila <>
    Signed-off-by: Greg Kroah-Hartman <>
  6. @tiwai @gregkh

    ALSA: usb-audio: Fix regression by disconnection-race-fix patch

    tiwai committed with gregkh
    [NOTE: the regression below is found only in 3.2-3.4 stable trees, so
           there is no upstream commit corresponding to this patch]
    The recent fix for the race at disconnection of usb-audio devices
    (upstream commit 978520b) triggers Oops when a device is unplugged
    while playing on 3.2 and 3.4 kernels.  The culprit is that the
    shutdown flag check was wrongly added around the urb deactivation code
    snippet.  The urb deactivation code has to be performed even after the
    device disconnected.  Otherwise it remains undead and pokes the wild
    access in the end.
    The regression fix is simply reverting the shutdown flag check in that
    Reported-and-tested-by: Chris J Arges <>
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
  7. @gregkh

    ahci: Add identifiers for ASM106x devices

    Alan Cox committed with gregkh
    commit 7b4f6ec upstream.
    They don't always appear as AHCI class devices but instead as IDE class.
    Based on an initial patch by Hiroaki Nito
    Signed-off-by: Alan Cox <>
    Signed-off-by: Jeff Garzik <>
    Signed-off-by: Abdallah Chatila <>
    Signed-off-by: Greg Kroah-Hartman <>
  8. @gregkh

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

    Zhenzhong Duan committed with gregkh
    commit 9f9c9cb 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
       # 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.
    [ checkpatch fixes]
    Signed-off-by: Zhenzhong Duan <>
    Cc: Feng Jin <>
    Cc: Jean Delvare <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Abdallah Chatila <>
    Signed-off-by: Greg Kroah-Hartman <>
  9. @gregkh

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

    Zhenzhong Duan committed with gregkh
    commit f1d8e61 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
    [ tweak code comment]
    Signed-off-by: Zhenzhong Duan <>
    Cc: Feng Jin <>
    Cc: Jean Delvare <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Abdallah Chatila <>
    Signed-off-by: Greg Kroah-Hartman <>
  10. @gregkh

    SCSI: sd: Reshuffle init_sd to avoid crash

    Joel D. Diaz committed with gregkh
    commit afd5e34 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 <>
    Signed-off-by: Hannes Reinecke <>
    Signed-off-by: James Bottomley <>
    Cc: CAI Qian <>
    Signed-off-by: Greg Kroah-Hartman <>
  11. @gregkh

    usb: dwc3: gadget: fix ep->maxburst for ep0

    Pratyush Anand committed with gregkh
    commit 6048e4c upstream.
    dwc3_gadget_set_ep_config expects maxburst as incremented by 1. So, by
    default initialize ep->maxburst to 1 for ep0.
    Signed-off-by: Pratyush Anand <>
    Signed-off-by: Felipe Balbi <>
    Signed-off-by: Greg Kroah-Hartman <>
  12. @gregkh

    USB: UHCI: fix IRQ race during initialization

    Alan Stern committed with gregkh
    commit 0f815a0 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
    Signed-off-by: Alan Stern <>
    Reported-by: Don Zickus <>
    Tested-by: "Huang, Adrian (ISS Linux TW)" <>
    Signed-off-by: Greg Kroah-Hartman <>
  13. @bjorn-helgaas @gregkh

    PCI: shpchp: Handle push button event asynchronously

    bjorn-helgaas committed with gregkh
    commit d347e75 upstream.
    Use non-ordered workqueue for attention button events.
    Attention button events on each slot can be handled asynchronously. So
    we should use non-ordered workqueue. This patch also removes ordered
    workqueue in shpchp as a result.
    486b10b ("PCI: pciehp: Handle push button event asynchronously") made
    the same change to pciehp.  I split this out from a patch by Yijing Wang
    <> so we fix one thing at a time and to make the
    shpchp history correspond more closely with the pciehp history.
    Signed-off-by: Bjorn Helgaas <>
    CC: Kenji Kaneshige <>
    Signed-off-by: Greg Kroah-Hartman <>
  14. @YijingWang @gregkh

    PCI: pciehp: Use per-slot workqueues to avoid deadlock

    YijingWang committed with gregkh
    commit c2be6f9 upstream.
    When we have a hotplug-capable PCIe port with a second hotplug-capable
    PCIe port below it, removing the device below the upstream port causes
    a deadlock.
    The deadlock happens because we use the pciehp_wq workqueue to run
    pciehp_power_thread(), which uses pciehp_disable_slot() to remove devices
    below the upstream port.  When we remove the downstream PCIe port, we call
    pciehp_remove(), the pciehp driver's .remove() method.  That calls
    flush_workqueue(pciehp_wq), which deadlocks because the
    pciehp_power_thread() work item is still running.
    This patch avoids the deadlock by creating a workqueue for every PCIe port
    and removing the single shared workqueue.
    Here's the call path that leads to the deadlock:
        queue_work(pciehp_wq)                   # queue pciehp_power_thread
    	      pciehp_remove                 # pciehp driver .remove method
    This is fairly urgent because it can be caused by simply unplugging a
    Thunderbolt adapter, as reported by Daniel below.
    [bhelgaas: changelog]
    Reported-and-tested-by: Daniel J Blueman <>
    Reviewed-by: Kenji Kaneshige <>
    Signed-off-by: Yijing Wang <>
    Signed-off-by: Bjorn Helgaas <>
    Signed-off-by: Greg Kroah-Hartman <>
  15. @ColinIanKing @gregkh

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

    ColinIanKing committed with gregkh
    commit 9e16721 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 3c07635 ("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.
    Signed-off-by: Colin Ian King <>
    Signed-off-by: Bjorn Helgaas <>
    Signed-off-by: Greg Kroah-Hartman <>
  16. @gregkh

    PCI/AER: pci_get_domain_bus_and_slot() call missing required pci_dev_…

    Betty Dall committed with gregkh
    commit a82b6af upstream.
    The function aer_recover_queue() calls pci_get_domain_bus_and_slot(), which
    requires that the caller decrement the reference count with pci_dev_put().
    This patch adds the missing call to pci_dev_put().
    Signed-off-by: Betty Dall <>
    Signed-off-by: Bjorn Helgaas <>
    Reviewed-by: Shuah Khan <>
    Signed-off-by: Greg Kroah-Hartman <>
  17. @utrace @gregkh

    wake_up_process() should be never used to wakeup a TASK_STOPPED/TRACE…

    utrace committed with gregkh
    …D task
    commit 9067ac8 upstream.
    wake_up_process() should never wakeup a TASK_STOPPED/TRACED task.
    Change it to use TASK_NORMAL and add the WARN_ON().
    TASK_ALL has no other users, probably can be killed.
    Signed-off-by: Oleg Nesterov <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  18. @utrace @gregkh

    ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL

    utrace committed with gregkh
    commit 9899d11 upstream.
    putreg() assumes that the tracee is not running and pt_regs_access() can
    safely play with its stack.  However a killed tracee can return from
    ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
    that debugger can actually read/modify the kernel stack until the tracee
    does SAVE_REST again.
    set_task_blockstep() can race with SIGKILL too and in some sense this
    race is even worse, the very fact the tracee can be woken up breaks the
    As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
    call, this ensures that nobody can ever wakeup the tracee while the
    debugger looks at it.  Not only this fixes the mentioned problems, we
    can do some cleanups/simplifications in arch_ptrace() paths.
    Probably ptrace_unfreeze_traced() needs more callers, for example it
    makes sense to make the tracee killable for oom-killer before
    While at it, add the comment into may_ptrace_stop() to explain why
    ptrace_stop() still can't rely on SIGKILL and signal_pending_state().
    Reported-by: Salman Qazi <>
    Reported-by: Suleiman Souhlal <>
    Suggested-by: Linus Torvalds <>
    Signed-off-by: Oleg Nesterov <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  19. @utrace @gregkh

    ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up()

    utrace committed with gregkh
    commit 910ffdb upstream.
    Cleanup and preparation for the next change.
    signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
    actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
    necessary mask.
    Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
    signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
    which adds __TASK_TRACED.
    This way ptrace_signal_wake_up() can work "inside" ptrace_request()
    even if the tracee doesn't have the TASK_WAKEKILL bit set.
    Signed-off-by: Oleg Nesterov <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  20. @gregkh

    evm: checking if removexattr is not a NULL

    Dmitry Kasatkin committed with gregkh
    commit a67adb9 upstream.
    The following lines of code produce a kernel oops.
    fchmod(fd, 0666);
    [  139.922364] BUG: unable to handle kernel NULL pointer dereference at   (null)
    [  139.924982] IP: [<  (null)>]   (null)
    [  139.924982] *pde = 00000000
    [  139.924982] Oops: 0000 [#5] SMP
    [  139.924982] Modules linked in: fuse dm_crypt dm_mod i2c_piix4 serio_raw evdev binfmt_misc button
    [  139.924982] Pid: 3070, comm: acpid Tainted: G      D      3.8.0-rc2-kds+ #465 Bochs Bochs
    [  139.924982] EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 0
    [  139.924982] EIP is at 0x0
    [  139.924982] EAX: cf5ef000 EBX: cf5ef000 ECX: c143d600 EDX: c15225f2
    [  139.924982] ESI: cf4d2a1c EDI: cf4d2a1c EBP: cc02df10 ESP: cc02dee4
    [  139.924982]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
    [  139.924982] CR0: 80050033 CR2: 00000000 CR3: 0c059000 CR4: 000006d0
    [  139.924982] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
    [  139.924982] DR6: ffff0ff0 DR7: 00000400
    [  139.924982] Process acpid (pid: 3070, ti=cc02c000 task=d7705340 task.ti=cc02c000)
    [  139.924982] Stack:
    [  139.924982]  c1203c88 00000000 cc02def4 cf4d2a1c ae21eefa 471b60d5 1083c1ba c26a5940
    [  139.924982]  e891fb5e 00000041 00000004 cc02df1c c1203964 00000000 cc02df4c c10e20c3
    [  139.924982]  00000002 00000000 00000000 22222222 c1ff2222 cf5ef000 00000000 d76efb08
    [  139.924982] Call Trace:
    [  139.924982]  [<c1203c88>] ? evm_update_evmxattr+0x5b/0x62
    [  139.924982]  [<c1203964>] evm_inode_post_setattr+0x22/0x26
    [  139.924982]  [<c10e20c3>] notify_change+0x25f/0x281
    [  139.924982]  [<c10cbf56>] chmod_common+0x59/0x76
    [  139.924982]  [<c10e27a1>] ? put_unused_fd+0x33/0x33
    [  139.924982]  [<c10cca09>] sys_fchmod+0x39/0x5c
    [  139.924982]  [<c13f4f30>] syscall_call+0x7/0xb
    [  139.924982] Code:  Bad EIP value.
    This happens because sockets do not define the removexattr operation.
    Before removing the xattr, verify the removexattr function pointer is
    not NULL.
    Signed-off-by: Dmitry Kasatkin <>
    Signed-off-by: Mimi Zohar <>
    Signed-off-by: James Morris <>
    Signed-off-by: Greg Kroah-Hartman <>
  21. @gregkh

    ftrace: Be first to run code modification on modules

    Steven Rostedt committed with gregkh
    commit c1bf08a 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.
    Acked-by: Masami Hiramatsu <>
    Reported-by: Frank Ch. Eigler <>
    Signed-off-by: Steven Rostedt <>
  22. @gregkh

    libata: ahci: Add support for Enmotus Bobcat device.

    Hugh Daschbach committed with gregkh
    commit 7f9c9f8 upstream.
    Silicon does not support standard AHCI BAR assignment.  Add
    vendor/device exception to force BAR 2.
    Signed-off-by: Hugh Daschbach <>
    Signed-off-by: Jeff Garzik <>
    Signed-off-by: Greg Kroah-Hartman <>
  23. @ickle @gregkh

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

    ickle committed with gregkh
    commit 262b6d3 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 bcf50e2
    Author: Chris Wilson <>
    Date:   Sun Nov 21 22:07:12 2010 +0000
        drm/i915: Handle pagefaults in execbuffer user relocations
    Signed-off-by: Chris Wilson <>
    Cc: Daniel Vetter <>
    Signed-off-by: Daniel Vetter <>
Commits on Jan 21, 2013
  1. @gregkh

    Linux 3.4.27

    gregkh committed
  2. @bwhacks @gregkh

    staging: vt6656: Fix inconsistent structure packing

    bwhacks committed with gregkh
    commit 1ee4c55 upstream.
    vt6656 has several headers that use the #pragma pack(1) directive to
    enable structure packing, but never disable it.  The layout of
    structures defined in other headers can then depend on which order the
    various headers are included in, breaking the One Definition Rule.
    In practice this resulted in crashes on x86_64 until the order of header
    inclusion was changed for some files in commit 11d404c ('staging:
    vt6656: fix headers and add cfg80211.').  But we need a proper fix that
    won't be affected by future changes to the order of inclusion.
    This removes the #pragma pack(1) directives and adds __packed to the
    structure definitions for which packing appears to have been intended.
    Reported-and-tested-by: Malcolm Priestley <>
    Signed-off-by: Ben Hutchings <>
    Signed-off-by: Greg Kroah-Hartman <>
  3. @tormodvolden @gregkh

    staging: wlan-ng: Fix clamping of returned SSID length

    tormodvolden committed with gregkh
    commit 811a37e upstream.
    Commit 2e25421 broke listing of available network names, since it
    clamped the length of the returned SSID to WLAN_BSSID_LEN (6) instead of
    Signed-off-by: Tormod Volden <>
    Signed-off-by: Greg Kroah-Hartman <>
  4. @mripard @gregkh

    tty: 8250_dw: Fix inverted arguments to serial_out in IRQ handler

    mripard committed with gregkh
    commit 68e56cb upstream.
    Signed-off-by: Maxime Ripard <>
    Signed-off-by: Greg Kroah-Hartman <>
  5. @gregkh

    serial:ifx6x60:Delete SPI timer when shut down port

    chao bi committed with gregkh
    commit 014b9b4 upstream.
    When shut down SPI port, it's possible that MRDY has been asserted and a SPI
    timer was activated waiting for SRDY assert, in the case, it needs to delete
    this timer.
    Signed-off-by: Chen Jun <>
    Signed-off-by: channing <>
    Signed-off-by: Greg Kroah-Hartman <>
  6. @bmork @gregkh

    USB: option: blacklist network interface on ONDA MT8205 4G LTE

    bmork committed with gregkh
    Signed-off-by: Bjørn Mork <>
    commit 2291dff upstream.
    The driver description files gives these names to the vendor specific
    functions on this modem:
     Diag   VID_19D2&PID_0265&MI_00
     NMEA   VID_19D2&PID_0265&MI_01
     AT cmd VID_19D2&PID_0265&MI_02
     Modem  VID_19D2&PID_0265&MI_03
     Net    VID_19D2&PID_0265&MI_04
    Signed-off-by: Bjørn Mork <>
    Signed-off-by: Greg Kroah-Hartman <>
  7. @bmork @gregkh

    USB: option: add TP-LINK HSUPA Modem MA180

    bmork committed with gregkh
    commit 99beb2e upstream.
    The driver description files gives these names to the vendor specific
    functions on this modem:
     Diagnostics VID_2357&PID_0201&MI_00
     NMEA        VID_2357&PID_0201&MI_01
     Modem       VID_2357&PID_0201&MI_03
     Networkcard VID_2357&PID_0201&MI_04
    Reported-by: Thomas Schäfer <>
    Signed-off-by: Bjørn Mork <>
    Signed-off-by: Greg Kroah-Hartman <>
  8. @freddy77 @gregkh

    xen: Fix stack corruption in xen_failsafe_callback for 32bit PVOPS gu…

    freddy77 committed with gregkh
    commit 9174adb upstream.
    This fixes CVE-2013-0190 / XSA-40
    There has been an error on the xen_failsafe_callback path for failed
    iret, which causes the stack pointer to be wrong when entering the
    iret_exc error path.  This can result in the kernel crashing.
    In the classic kernel case, the relevant code looked a little like:
            popl %eax      # Error code from hypervisor
            jz 5f
            addl $16,%esp
            jmp iret_exc   # Hypervisor said iret fault
    5:      addl $16,%esp
                           # Hypervisor said segment selector fault
    Here, there are two identical addls on either option of a branch which
    appears to have been optimised by hoisting it above the jz, and
    converting it to an lea, which leaves the flags register unaffected.
    In the PVOPS case, the code looks like:
            popl_cfi %eax         # Error from the hypervisor
            lea 16(%esp),%esp     # Add $16 before choosing fault path
            CFI_ADJUST_CFA_OFFSET -16
            jz 5f
            addl $16,%esp         # Incorrectly adjust %esp again
            jmp iret_exc
    It is possible unprivileged userspace applications to cause this
    behaviour, for example by loading an LDT code selector, then changing
    the code selector to be not-present.  At this point, there is a race
    condition where it is possible for the hypervisor to return back to
    userspace from an interrupt, fault on its own iret, and inject a
    failsafe_callback into the kernel.
    This bug has been present since the introduction of Xen PVOPS support
    in commit 5ead97c (xen: Core Xen implementation), in 2.6.23.
    Signed-off-by: Frediano Ziglio <>
    Signed-off-by: Andrew Cooper <>
    Signed-off-by: Konrad Rzeszutek Wilk <>
    Signed-off-by: Greg Kroah-Hartman <>
  9. @mswilson @gregkh

    xen/grant-table: correctly initialize grant table version 1

    mswilson committed with gregkh
    commit d0b4d64 upstream.
    Commit 85ff6ac (xen/granttable: Grant
    tables V2 implementation) changed the GREFS_PER_GRANT_FRAME macro from
    a constant to a conditional expression. The expression depends on
    grant_table_version being appropriately set. Unfortunately, at init
    time grant_table_version will be 0. The GREFS_PER_GRANT_FRAME
    conditional expression checks for "grant_table_version == 1", and
    therefore returns the number of grant references per frame for v2.
    This causes gnttab_init() to allocate fewer pages for gnttab_list, as
    a frame can old half the number of v2 entries than v1 entries. After
    gnttab_resume() is called, grant_table_version is appropriately
    set. nr_init_grefs will then be miscalculated and gnttab_free_count
    will hold a value larger than the actual number of free gref entries.
    If a guest is heavily utilizing improperly initialized v1 grant
    tables, memory corruption can occur. One common manifestation is
    corruption of the vmalloc list, resulting in a poisoned pointer
    derefrence when accessing /proc/meminfo or /proc/vmallocinfo:
    [   40.770064] BUG: unable to handle kernel paging request at 0000200200001407
    [   40.770083] IP: [<ffffffff811a6fb0>] get_vmalloc_info+0x70/0x110
    [   40.770102] PGD 0
    [   40.770107] Oops: 0000 [#1] SMP
    [   40.770114] CPU 10
    This patch introduces a static variable, grefs_per_grant_frame, to
    cache the calculated value. gnttab_init() now calls
    gnttab_request_version() early so that grant_table_version and
    grefs_per_grant_frame can be appropriately set. A few BUG_ON()s have
    been added to prevent this type of bug from reoccurring in the future.
    Signed-off-by: Matt Wilson <>
    Reviewed-and-Tested-by: Steven Noonan <>
    Acked-by: Ian Campbell <>
    Cc: Konrad Rzeszutek Wilk <>
    Cc: Annie Li <>
    Signed-off-by: Konrad Rzeszutek Wilk <>
    Signed-off-by: Greg Kroah-Hartman <>
  10. @gregkh

    drbd: add missing part_round_stats to _drbd_start_io_acct

    Philipp Reisner committed with gregkh
    commit 72585d2 upstream.
    Without this, iostat frequently sees bogus svctime and >= 100% "utilization".
    Signed-off-by: Philipp Reisner <>
    Signed-off-by: Lars Ellenberg <>
    Cc: Raoul Bhatia <>
    Signed-off-by: Greg Kroah-Hartman <>
  11. @gregkh

    igb: release already assigned MSI-X interrupts if setup fails

    Stefan Assmann committed with gregkh
    commit 52285b7 upstream.
    During MSI-X setup the system might run out of vectors. If this happens the
    already assigned vectors for this NIC should be freed before trying the
    disable MSI-X. Failing to do so results in the following oops.
    kernel BUG at drivers/pci/msi.c:341!
    Call Trace:
     [<ffffffff8128f39d>] pci_disable_msix+0x3d/0x60
     [<ffffffffa037d1ce>] igb_reset_interrupt_capability+0x27/0x5c [igb]
     [<ffffffffa037d229>] igb_clear_interrupt_scheme+0x26/0x2d [igb]
     [<ffffffffa0384268>] igb_request_irq+0x73/0x297 [igb]
     [<ffffffffa0384554>] __igb_open+0xc8/0x223 [igb]
     [<ffffffffa0384815>] igb_open+0x13/0x15 [igb]
     [<ffffffff8144592f>] __dev_open+0xbf/0x120
     [<ffffffff81443e51>] __dev_change_flags+0xa1/0x180
     [<ffffffff81445828>] dev_change_flags+0x28/0x70
     [<ffffffff814af537>] devinet_ioctl+0x5b7/0x620
     [<ffffffff814b01c8>] inet_ioctl+0x88/0xa0
     [<ffffffff8142e8a0>] sock_do_ioctl+0x30/0x70
     [<ffffffff8142ecf2>] sock_ioctl+0x72/0x270
     [<ffffffff8118062c>] do_vfs_ioctl+0x8c/0x340
     [<ffffffff81180981>] sys_ioctl+0xa1/0xb0
     [<ffffffff815161a9>] system_call_fastpath+0x16/0x1b
    Code: 48 89 df e8 1f 40 ed ff 4d 39 e6 49 8b 45 10 75 b6 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 8b 7b 20 e8 3e 91 db ff eb ae <0f> 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00
    RIP  [<ffffffff8128e144>] free_msi_irqs+0x124/0x130
     RSP <ffff880037503bd8>
    Signed-off-by: Stefan Assmann <>
    Tested-by: Aaron Brown <>
    Signed-off-by: Jeff Kirsher <>
    Signed-off-by: Abdallah Chatila <>
  12. @gregkh

    intel-iommu: Prevent devices with RMRRs from being placed into SI Domain

    Tom Mingarelli committed with gregkh
    commit ea2447f upstream.
    This patch is to prevent non-USB devices that have RMRRs associated with them from
    being placed into the SI Domain during init. This fixes the issue where the RMRR info
    for devices being placed in and out of the SI Domain gets lost.
    Signed-off-by: Thomas Mingarelli <>
    Tested-by: Shuah Khan <>
    Reviewed-by: Donald Dutile <>
    Reviewed-by: Alex Williamson <>
    Signed-off-by: Joerg Roedel <>
    Cc: CAI Qian <>
    Signed-off-by: Greg Kroah-Hartman <>
Something went wrong with that request. Please try again.