Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Jan 18, 2012
  1. @gregkh

    Linux 3.1.10

    gregkh authored
  2. @lnussel @gregkh

    x86: Fix mmap random address range

    lnussel authored gregkh committed
    commit 9af0c7a upstream.
    On x86_32 casting the unsigned int result of get_random_int() to
    long may result in a negative value.  On x86_32 the range of
    mmap_rnd() therefore was -255 to 255.  The 32bit mode on x86_64
    used 0 to 255 as intended.
    The bug was introduced by 675a081 ("x86: unify mmap_{32|64}.c")
    in January 2008.
    Signed-off-by: Ludwig Nussel <>
    Cc: Linus Torvalds <>
    Cc: "H. Peter Anvin" <>
    Cc: Harvey Harrison <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Ingo Molnar <>
    Signed-off-by: Greg Kroah-Hartman <>
  3. @gregkh

    memcg: add mem_cgroup_replace_page_cache() to fix LRU issue

    KAMEZAWA Hiroyuki authored gregkh committed
    commit ab936cb upstream.
    Commit ef6a3c6 ("mm: add replace_page_cache_page() function") added a
    function replace_page_cache_page().  This function replaces a page in the
    radix-tree with a new page.  WHen doing this, memory cgroup needs to fix
    up the accounting information.  memcg need to check PCG_USED bit etc.
    In some(many?) cases, 'newpage' is on LRU before calling
    replace_page_cache().  So, memcg's LRU accounting information should be
    fixed, too.
    This patch adds mem_cgroup_replace_page_cache() and removes the old hooks.
     In that function, old pages will be unaccounted without touching
    res_counter and new page will be accounted to the memcg (of old page).
    WHen overwriting pc->mem_cgroup of newpage, take zone->lru_lock and avoid
    races with LRU handling.
      replace_page_cache_page() is called by FUSE code in its splice() handling.
      Here, 'newpage' is replacing oldpage but this newpage is not a newly allocated
      page and may be on LRU. LRU mis-accounting will be critical for memory cgroup
      because rmdir() checks the whole LRU is empty and there is no account leak.
      If a page is on the other LRU than it should be, rmdir() will fail.
    This bug was added in March 2011, but no bug report yet.  I guess there
    are not many people who use memcg and FUSE at the same time with upstream
    The result of this bug is that admin cannot destroy a memcg because of
    account leak.  So, no panic, no deadlock.  And, even if an active cgroup
    exist, umount can succseed.  So no problem at shutdown.
    Signed-off-by: KAMEZAWA Hiroyuki <>
    Acked-by: Johannes Weiner <>
    Acked-by: Michal Hocko <>
    Cc: Miklos Szeredi <>
    Cc: Hugh Dickins <>
    Signed-off-by: Andrew Morton <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  4. @sgruszka @gregkh

    mac80211: fix rx->key NULL pointer dereference in promiscuous mode

    sgruszka authored gregkh committed
    commit 1140afa upstream.
    commit 816c04f
    Author: Christian Lamparter <>
    Date:   Sat Apr 30 15:24:30 2011 +0200
        mac80211: consolidate MIC failure report handling
    is possible to that we dereference rx->key == NULL when driver set
    promiscuous mode. This happen with rt73usb and rt61pci at least.
    Before the commit we always check rx->key against NULL, so I assume
    fix should be done in mac80211 (also mic_fail path has similar check).
    Reported-by: Stuart D Gathman <>
    Reported-by: Kai Wohlfahrt <>
    Signed-off-by: Stanislaw Gruszka <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
  5. @lwfinger @gregkh

    rtl8192se: Fix BUG caused by failure to check skb allocation

    lwfinger authored gregkh committed
    commit d90db4b upstream.
    When downloading firmware into the device, the driver fails to check the
    return when allocating an skb. When the allocation fails, a BUG can be
    generated, as seen in
    Signed-off-by: Larry Finger <>
    Signed-off-by: John W. Linville <>
    Signed-off-by: Greg Kroah-Hartman <>
  6. @bjorn-helgaas @gregkh

    PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USB

    bjorn-helgaas authored gregkh committed
    commit eb31aae upstream.
    Some Dell BIOSes have MCFG tables that don't report the entire
    MMCONFIG area claimed by the chipset.  If we move PCI devices into
    that claimed-but-unreported area, they don't work.
    This quirk reads the AMD MMCONFIG MSRs and adds PNP0C01 resources as
    needed to cover the entire area.
    Example problem scenario:
      BIOS-e820: 00000000cfec5400 - 00000000d4000000 (reserved)
      Fam 10h mmconf [d0000000, dfffffff]
      PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xd0000000-0xd3ffffff] (base 0xd0000000)
      pnp 00:0c: [mem 0xd0000000-0xd3ffffff]
      pci 0000:00:12.0: reg 10: [mem 0xffb00000-0xffb00fff]
      pci 0000:00:12.0: no compatible bridge window for [mem 0xffb00000-0xffb00fff]
      pci 0000:00:12.0: BAR 0: assigned [mem 0xd4000000-0xd40000ff]
    Reported-by: Lisa Salimbas <>
    Reported-by: <>
    Tested-by: dann frazier <>
    Signed-off-by: Bjorn Helgaas <>
    Signed-off-by: Jesse Barnes <>
    Signed-off-by: Greg Kroah-Hartman <>
  7. @gregkh

    slub: fix a possible memleak in __slab_alloc()

    Eric Dumazet authored gregkh committed
    commit 73736e0 upstream.
    Zhihua Che reported a possible memleak in slub allocator on
    CONFIG_PREEMPT=y builds.
    It is possible current thread migrates right before disabling irqs in
    __slab_alloc(). We must check again c->freelist, and perform a normal
    allocation instead of scratching c->freelist.
    Many thanks to Zhihua Che for spotting this bug, introduced in 2.6.39
    V2: Its also possible an IRQ freed one (or several) object(s) and
    populated c->freelist, so its not a CONFIG_PREEMPT only problem.
    Reported-by: Zhihua Che <>
    Signed-off-by: Eric Dumazet <>
    Acked-by: Christoph Lameter <>
    Signed-off-by: Pekka Enberg <>
    Signed-off-by: Greg Kroah-Hartman <>
  8. @gregkh

    ima: fix invalid memory reference

    Roberto Sassu authored gregkh committed
    commit 7b7e591 upstream.
    Don't free a valid measurement entry on TPM PCR extend failure.
    Signed-off-by: Roberto Sassu <>
    Signed-off-by: Mimi Zohar <>
    Signed-off-by: Greg Kroah-Hartman <>
  9. @gregkh

    ima: free duplicate measurement memory

    Roberto Sassu authored gregkh committed
    commit 45fae74 upstream.
    Info about new measurements are cached in the iint for performance.  When
    the inode is flushed from cache, the associated iint is flushed as well.
    Subsequent access to the inode will cause the inode to be re-measured and
    will attempt to add a duplicate entry to the measurement list.
    This patch frees the duplicate measurement memory, fixing a memory leak.
    Signed-off-by: Roberto Sassu <>
    Signed-off-by: Mimi Zohar <>
    Signed-off-by: Greg Kroah-Hartman <>
  10. @neilbrown @gregkh

    md/raid1: perform bad-block tests for WriteMostly devices too.

    neilbrown authored gregkh committed
    commit 307729c upstream.
    We normally try to avoid reading from write-mostly devices, but when
    we do we really have to check for bad blocks and be sure not to
    try reading them.
    With the current code, best_good_sectors might not get set and that
    causes zero-length read requests to be send down which is very
    This bug was introduced in commit d2eb35a and so the patch
    is suitable for 3.1.x and 3.2.x
    Reported-and-tested-by: Michał Mirosław <>
    Reported-and-tested-by: Art -kwaak- van Breemen <>
    Signed-off-by: NeilBrown <>
    Signed-off-by: Greg Kroah-Hartman <>
  11. @gregkh

    xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.

    Ian Campbell authored gregkh committed
    commit 9e7860c upstream.
    Haogang Chen found out that:
     There is a potential integer overflow in process_msg() that could result
     in cross-domain attack.
     	body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH);
     When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent
     call to xb_read() would write to a zero-length buffer.
     The other end of this connection is always the xenstore backend daemon
     so there is no guest (malicious or otherwise) which can do this. The
     xenstore daemon is a trusted component in the system.
     However this seem like a reasonable robustness improvement so we should
     have it.
    And Ian when read the API docs found that:
            The payload length (len field of the header) is limited to 4096
            (XENSTORE_PAYLOAD_MAX) in both directions.  If a client exceeds the
            limit, its xenstored connection will be immediately killed by
            xenstored, which is usually catastrophic from the client's point of
            view.  Clients (particularly domains, which cannot just reconnect)
            should avoid this.
    so this patch checks against that instead.
    This also avoids a potential integer overflow pointed out by Haogang Chen.
    Signed-off-by: Ian Campbell <>
    Cc: Haogang Chen <>
    Signed-off-by: Konrad Rzeszutek Wilk <>
    Signed-off-by: Greg Kroah-Hartman <>
  12. @gregkh

    SCSI: mpt2sas : Fix for memory allocation error for large host credits authored gregkh committed
    commit aff132d upstream.
    The amount of memory required for tracking chain buffers is rather
    large, and when the host credit count is big, memory allocation
    failure occurs inside __get_free_pages.
    The fix is to limit the number of chains to 100,000.  In addition,
    the number of host credits is limited to 30,000 IOs. However this
    limitation can be overridden this using the command line option
    max_queue_depth.  The algorithm for calculating the
    reply_post_queue_depth is changed so that it is equal to
    (reply_free_queue_depth + 16), previously it was (reply_free_queue_depth * 2).
    Signed-off-by: Nagalakshmi Nandigama <>
    Signed-off-by: James Bottomley <>
    Signed-off-by: Greg Kroah-Hartman <>
  13. @gregkh

    SCSI: mpt2sas: Release spinlock for the raid device list before block… authored gregkh committed
    …ing it
    commit 30c4328 upstream.
    Added code to release the spinlock that is used to protect the
    raid device list before calling a function that can block. The
    blocking was causing a reschedule, and subsequently it is tried
    to acquire the same lock, resulting in a panic (NMI Watchdog
    detecting a CPU lockup).
    Signed-off-by: Nagalakshmi Nandigama <>
    Signed-off-by: James Bottomley <>
    Signed-off-by: Greg Kroah-Hartman <>
  14. @bjorn-helgaas @gregkh

    x86/PCI: build amd_bus.o only when CONFIG_AMD_NB=y

    bjorn-helgaas authored gregkh committed
    commit 5cf9a4e upstream.
    We only need amd_bus.o for AMD systems with PCI.  arch/x86/pci/Makefile
    already depends on CONFIG_PCI=y, so this patch just adds the dependency
    Cc: Yinghai Lu <>
    Signed-off-by: Bjorn Helgaas <>
    Signed-off-by: Linus Torvalds <>
    Signed-off-by: Greg Kroah-Hartman <>
  15. @bjorn-helgaas @gregkh

    x86/PCI: amd: factor out MMCONFIG discovery

    bjorn-helgaas authored gregkh committed
    commit 24d25db upstream.
    This factors out the AMD native MMCONFIG discovery so we can use it
    outside amd_bus.c.
    amd_bus.c reads AMD MSRs so it can remove the MMCONFIG area from the
    PCI resources.  We may also need the MMCONFIG information to work
    around BIOS defects in the ACPI MCFG table.
    Cc: Borislav Petkov <>
    Cc: Yinghai Lu <>
    Signed-off-by: Bjorn Helgaas <>
    Signed-off-by: Jesse Barnes <>
    Signed-off-by: Greg Kroah-Hartman <>
  16. @gregkh

    x86/PCI: Ignore CPU non-addressable _CRS reserved memory resources

    Gary Hade authored gregkh committed
    commit ae5cd86 upstream.
    This assures that a _CRS reserved host bridge window or window region is
    not used if it is not addressable by the CPU.  The new code either trims
    the window to exclude the non-addressable portion or totally ignores the
    window if the entire window is non-addressable.
    The current code has been shown to be problematic with 32-bit non-PAE
    kernels on systems where _CRS reserves resources above 4GB.
    Signed-off-by: Gary Hade <>
    Reviewed-by: Bjorn Helgaas <>
    Cc: Thomas Renninger <>
    Signed-off-by: Jesse Barnes <>
    Signed-off-by: Greg Kroah-Hartman <>
  17. @ebiederm @gregkh

    PCI: msi: Disable msi interrupts when we initialize a pci device

    ebiederm authored gregkh committed
    commit a776c49 upstream.
    I traced a nasty kexec on panic boot failure to the fact that we had
    screaming msi interrupts and we were not disabling the msi messages at
    kernel startup.  The booting kernel had not enabled those interupts so
    was not prepared to handle them.
    I can see no reason why we would ever want to leave the msi interrupts
    enabled at boot if something else has enabled those interrupts.  The pci
    spec specifies that msi interrupts should be off by default.  Drivers
    are expected to enable the msi interrupts if they want to use them.  Our
    interrupt handling code reprograms the interrupt handlers at boot and
    will not be be able to do anything useful with an unexpected interrupt.
    This patch applies cleanly all of the way back to 2.6.32 where I noticed
    the problem.
    Signed-off-by: Eric W. Biederman <>
    Signed-off-by: Jesse Barnes <>
    Signed-off-by: Greg Kroah-Hartman <>
  18. @awilliam @gregkh

    PCI: Fix PCI_EXP_TYPE_RC_EC value

    awilliam authored gregkh committed
    commit 1830ea9 upstream.
    Spec shows this as 1010b = 0xa
    Signed-off-by: Alex Williamson <>
    Signed-off-by: Jesse Barnes <>
    Signed-off-by: Greg Kroah-Hartman <>
  19. @gregkh

    UBI: fix use-after-free on error path

    Artem Bityutskiy authored gregkh committed
    commit e57e0d8 upstream.
    When we fail to erase a PEB, we free the corresponding erase entry object,
    but then re-schedule this object if the error code was something like -EAGAIN.
    Obviously, it is a bug to use the object after we have freed it.
    Reported-by: Emese Revfy <>
    Signed-off-by: Artem Bityutskiy <>
    Signed-off-by: Greg Kroah-Hartman <>
  20. @gregkh

    UBI: fix missing scrub when there is a bit-flip

    Bhavesh Parekh authored gregkh committed
    commit e801e12 upstream.
    Under some cases, when scrubbing the PEB if we did not get the lock on
    the PEB it fails to scrub. Add that PEB again to the scrub list
    Artem: minor amendments.
    Signed-off-by: Bhavesh Parekh <>
    Signed-off-by: Artem Bityutskiy <>
    Signed-off-by: Greg Kroah-Hartman <>
  21. @gregkh

    HID: bump maximum global item tag report size to 96 bytes

    Chase Douglas authored gregkh committed
    commit e46e927 upstream.
    This allows the latest N-Trig devices to function properly.
    Signed-off-by: Chase Douglas <>
    Signed-off-by: Jiri Kosina <>
    Signed-off-by: Greg Kroah-Hartman <>
  22. @gregkh

    nfs: fix regression in handling of context= option in NFSv4

    Jeff Layton authored gregkh committed
    commit 8a0d551 upstream.
    Setting the security context of a NFSv4 mount via the context= mount
    option is currently broken. The NFSv4 codepath allocates a parsed
    options struct, and then parses the mount options to fill it. It
    eventually calls nfs4_remote_mount which calls security_init_mnt_opts.
    That clobbers the lsm_opts struct that was populated earlier. This bug
    also looks like it causes a small memory leak on each v4 mount where
    context= is used.
    Fix this by moving the initialization of the lsm_opts into
    nfs_alloc_parsed_mount_data. Also, add a destructor for
    nfs_parsed_mount_data to make it easier to free all of the allocations
    hanging off of it, and to ensure that the security_free_mnt_opts is
    called whenever security_init_mnt_opts is.
    I believe this regression was introduced quite some time ago, probably
    by commit c02d7ad.
    Signed-off-by: Jeff Layton <>
    Signed-off-by: Trond Myklebust <>
    Signed-off-by: Greg Kroah-Hartman <>
  23. @androsadamson @gregkh

    NFSv4: include bitmap in nfsv4 get acl data

    androsadamson authored gregkh committed
    commit bf118a3 upstream.
    The NFSv4 bitmap size is unbounded: a server can return an arbitrary
    sized bitmap in an FATTR4_WORD0_ACL request.  Replace using the
    nfs4_fattr_bitmap_maxsz as a guess to the maximum bitmask returned by a server
    with the inclusion of the bitmap (xdr length plus bitmasks) and the acl data
    xdr length to the (cached) acl page data.
    This is a general solution to commit e5012d1 "NFSv4.1: update
    nfs4_fattr_bitmap_maxsz" and fixes hitting a BUG_ON in xdr_shrink_bufhead
    when getting ACLs.
    Fix a bug in decode_getacl that returned -EINVAL on ACLs > page when getxattr
    was called with a NULL buffer, preventing ACL > PAGE_SIZE from being retrieved.
    Signed-off-by: Andy Adamson <>
    Signed-off-by: Trond Myklebust <>
    Signed-off-by: Greg Kroah-Hartman <>
  24. @neilbrown @gregkh

    NFS - fix recent breakage to NFS error handling.

    neilbrown authored gregkh committed
    commit 2edb6bc upstream.
    From c6d615d2b97fe305cbf123a8751ced859dca1d5e Mon Sep 17 00:00:00 2001
    From: NeilBrown <>
    Date: Wed, 16 Nov 2011 09:39:05 +1100
    Subject: NFS - fix recent breakage to NFS error handling.
    commit 02c24a8 made a small and
    presumably unintended change to write error handling in NFS.
    Previously an error from filemap_write_and_wait_range would only be of
    interest if nfs_file_fsync did not return an error.  After this commit,
    an error from filemap_write_and_wait_range would mean that (the rest of)
    nfs_file_fsync would not even be called.
    This means that:
     1/ you are more likely to see EIO than e.g. EDQUOT or ENOSPC.
     2/ NFS_CONTEXT_ERROR_WRITE remains set for longer so more writes are
    This patch restores previous behaviour.
    Cc: Josef Bacik <>
    Cc: Jan Kara <>
    Cc: Al Viro <>
    Signed-off-by: NeilBrown <>
    Signed-off-by: Trond Myklebust <>
    Signed-off-by: Greg Kroah-Hartman <>
  25. @androsadamson @gregkh

    NFSv4.1: fix backchannel slotid off-by-one bug

    androsadamson authored gregkh committed
    commit 61f2e51 upstream.
    Signed-off-by: Andy Adamson <>
    Signed-off-by: Trond Myklebust <>
    Signed-off-by: Greg Kroah-Hartman <>
  26. @chucklever @gregkh

    NFS: Retry mounting NFSROOT

    chucklever authored gregkh committed
    commit 43717c7 upstream.
    Lukas Razik <> reports that on his SPARC system,
    booting with an NFS root file system stopped working after commit
    56463e5 "NFS: Use super.c for NFSROOT mount option parsing."
    We found that the network switch to which Lukas' client was attached
    was delaying access to the LAN after the client's NIC driver reported
    that its link was up.  The delay was longer than the timeouts used in
    the NFS client during mounting.
    NFSROOT worked for Lukas before commit 56463e5 because in those
    kernels, the client's first operation was an rpcbind request to
    determine which port the NFS server was listening on.  When that
    request failed after a long timeout, the client simply selected the
    default NFS port (2049).  By that time the switch was allowing access
    to the LAN, and the mount succeeded.
    Neither of these client behaviors is desirable, so reverting 56463e5
    is really not a choice.  Instead, introduce a mechanism that retries
    the NFSROOT mount request several times.  This is the same tactic that
    normal user space NFS mounts employ to overcome server and network
    Signed-off-by: Lukas Razik <>
    [ cel: match kernel coding style, add proper patch description ]
    [ cel: add exponential back-off ]
    Signed-off-by: Chuck Lever <>
    Tested-by: Lukas Razik <>
    Signed-off-by: Trond Myklebust <>
    Signed-off-by: Greg Kroah-Hartman <>
  27. @gregkh

    radeon: Fix disabling PCI bus mastering on big endian hosts.

    Michel Dänzer authored gregkh committed
    commit 3df9690 upstream.
    It would previously write basically random bits to PCI configuration space...
    Not very surprising that the GPU tended to stop responding completely. The
    resulting MCE even froze the whole machine sometimes.
    Now resetting the GPU after a lockup has at least a fighting chance of
    Signed-off-by: Michel Dänzer <>
    Reviewed-by: Alex Deucher <>
    Signed-off-by: Dave Airlie <>
    Signed-off-by: Greg Kroah-Hartman <>
  28. @gregkh

    drm/radeon/kms: disable writeback on pre-R300 asics

    Alex Deucher authored gregkh committed
    commit 28eebb7 upstream.
    We often end up missing fences on older asics with
    writeback enabled which leads to delays in the userspace
    accel code, so just disable it by default on those asics.
    Reported-by: Helge Deller <>
    Reported-by: Dave Airlie <>
    Signed-off-by: Alex Deucher <>
    Signed-off-by: Dave Airlie <>
    Signed-off-by: Greg Kroah-Hartman <>
  29. @Zajec @gregkh

    drm/radeon/kms: workaround invalid AVI infoframe checksum issue

    Zajec authored gregkh committed
    commit 92db7f6 upstream.
    This change was verified to fix both issues with no video I've
    investigated. I've also checked checksum calculation with fglrx on:
    RV620, HD54xx, HD5450, HD6310, HD6320.
    Signed-off-by: Rafał Miłecki <>
    Signed-off-by: Dave Airlie <>
    Signed-off-by: Greg Kroah-Hartman <>
  30. @gregkh

    ideapad: Check if acpi already handle backlight power to avoid a page…

    Rene Bollford authored gregkh committed
    … fault
    commit d4afc77 upstream.
    This patch avoid a page fault in the ideapad-laptop extras when
    turning the backlight power on or off.
    Signed-off-by: Rene Bolldorf <>
    Signed-off-by: Matthew Garrett <>
    Signed-off-by: Jonathan Nieder <>
    Tested-by: Artem X <>
    Signed-off-by: Greg Kroah-Hartman <>
  31. @awilliam @gregkh

    KVM: Device assignment permission checks

    awilliam authored gregkh committed
    (cherry picked from commit 3d27e23)
    Only allow KVM device assignment to attach to devices which:
     - Are not bridges
     - Have BAR resources (assume others are special devices)
     - The user has permissions to use
    Assigning a bridge is a configuration error, it's not supported, and
    typically doesn't result in the behavior the user is expecting anyway.
    Devices without BAR resources are typically chipset components that
    also don't have host drivers.  We don't want users to hold such devices
    captive or cause system problems by fencing them off into an iommu
    domain.  We determine "permission to use" by testing whether the user
    has access to the PCI sysfs resource files.  By default a normal user
    will not have access to these files, so it provides a good indication
    that an administration agent has granted the user access to the device.
    [Yang Bai: add missing #include]
    [avi: fix comment style]
    Signed-off-by: Alex Williamson <>
    Signed-off-by: Yang Bai <>
    Signed-off-by: Marcelo Tosatti <>
    Signed-off-by: Greg Kroah-Hartman <>
  32. @awilliam @gregkh

    KVM: Remove ability to assign a device without iommu support

    awilliam authored gregkh committed
    (cherry picked from commit 4238737)
    This option has no users and it exposes a security hole that we
    can allow devices to be assigned without iommu protection.  Make
    KVM_DEV_ASSIGN_ENABLE_IOMMU a mandatory option.
    Signed-off-by: Alex Williamson <>
    Signed-off-by: Marcelo Tosatti <>
    Signed-off-by: Greg Kroah-Hartman <>
  33. @jan-kiszka @gregkh

    KVM: x86: Prevent starting PIT timers in the absence of irqchip support

    jan-kiszka authored gregkh committed
    (cherry picked from commit 0924ab2)
    User space may create the PIT and forgets about setting up the irqchips.
    In that case, firing PIT IRQs will crash the host:
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000128
    IP: [<ffffffffa10f6280>] kvm_set_irq+0x30/0x170 [kvm]
    Call Trace:
     [<ffffffffa11228c1>] pit_do_work+0x51/0xd0 [kvm]
     [<ffffffff81071431>] process_one_work+0x111/0x4d0
     [<ffffffff81071bb2>] worker_thread+0x152/0x340
     [<ffffffff81075c8e>] kthread+0x7e/0x90
     [<ffffffff815a4474>] kernel_thread_helper+0x4/0x10
    Prevent this by checking the irqchip mode before starting a timer. We
    can't deny creating the PIT if the irqchips aren't set up yet as
    current user land expects this order to work.
    Signed-off-by: Jan Kiszka <>
    Signed-off-by: Marcelo Tosatti <>
    Signed-off-by: Greg Kroah-Hartman <>
  34. @gregkh

    KVM guest: prevent tracing recursion with kvmclock

    Avi Kivity authored gregkh committed
    (cherry picked from commit 95ef1e5)
    Prevent tracing of preempt_disable() in get_cpu_var() in
    kvm_clock_read(). When CONFIG_DEBUG_PREEMPT is enabled,
    preempt_disable/enable() are traced and this causes the function_graph
    tracer to go into an infinite recursion. By open coding the
    preempt_disable() around the get_cpu_var(), we can use the notrace
    version which prevents preempt_disable/enable() from being traced and
    prevents the recursion.
    Based on a similar patch for Xen from Jeremy Fitzhardinge.
    Tested-by: Gleb Natapov <>
    Acked-by: Steven Rostedt <>
    Signed-off-by: Avi Kivity <>
    Signed-off-by: Greg Kroah-Hartman <>
  35. @tiwai @gregkh

    ALSA: hda - Fix the lost power-setup of seconary pins after PM resume

    tiwai authored gregkh committed
    commit f2cbba7 upstream.
    When multiple headphone or other detectable output pins are present,
    the power-map has to be updated after resume appropriately, but the
    current driver doesn't check all pins but only the first pin (since
    it's enough to check it for the mute-behavior).  This resulted in the
    silent output from the secondary outputs after PM resume.
    This patch fixes the problem by checking all pins at (re-)init time.
    Signed-off-by: Takashi Iwai <>
    Signed-off-by: Greg Kroah-Hartman <>
Something went wrong with that request. Please try again.