1. 12 Apr, 2017 22 commits
  2. 08 Apr, 2017 18 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.60 · 8f8ee970
      Greg Kroah-Hartman authored
      8f8ee970
    • Jason A. Donenfeld's avatar
      padata: avoid race in reordering · 84bd21a7
      Jason A. Donenfeld authored
      commit de5540d0 upstream.
      
      Under extremely heavy uses of padata, crashes occur, and with list
      debugging turned on, this happens instead:
      
      [87487.298728] WARNING: CPU: 1 PID: 882 at lib/list_debug.c:33
      __list_add+0xae/0x130
      [87487.301868] list_add corruption. prev->next should be next
      (ffffb17abfc043d0), but was ffff8dba70872c80. (prev=ffff8dba70872b00).
      [87487.339011]  [<ffffffff9a53d075>] dump_stack+0x68/0xa3
      [87487.342198]  [<ffffffff99e119a1>] ? console_unlock+0x281/0x6d0
      [87487.345364]  [<ffffffff99d6b91f>] __warn+0xff/0x140
      [87487.348513]  [<ffffffff99d6b9aa>] warn_slowpath_fmt+0x4a/0x50
      [87487.351659]  [<ffffffff9a58b5de>] __list_add+0xae/0x130
      [87487.354772]  [<ffffffff9add5094>] ? _raw_spin_lock+0x64/0x70
      [87487.357915]  [<ffffffff99eefd66>] padata_reorder+0x1e6/0x420
      [87487.361084]  [<ffffffff99ef0055>] padata_do_serial+0xa5/0x120
      
      padata_reorder calls list_add_tail with the list to which its adding
      locked, which seems correct:
      
      spin_lock(&squeue->serial.lock);
      list_add_tail(&padata->list, &squeue->serial.list);
      spin_unlock(&squeue->serial.lock);
      
      This therefore leaves only place where such inconsistency could occur:
      if padata->list is added at the same time on two different threads.
      This pdata pointer comes from the function call to
      padata_get_next(pd), which has in it the following block:
      
      next_queue = per_cpu_ptr(pd->pqueue, cpu);
      padata = NULL;
      reorder = &next_queue->reorder;
      if (!list_empty(&reorder->list)) {
             padata = list_entry(reorder->list.next,
                                 struct padata_priv, list);
             spin_lock(&reorder->lock);
             list_del_init(&padata->list);
             atomic_dec(&pd->reorder_objects);
             spin_unlock(&reorder->lock);
      
             pd->processed++;
      
             goto out;
      }
      out:
      return padata;
      
      I strongly suspect that the problem here is that two threads can race
      on reorder list. Even though the deletion is locked, call to
      list_entry is not locked, which means it's feasible that two threads
      pick up the same padata object and subsequently call list_add_tail on
      them at the same time. The fix is thus be hoist that lock outside of
      that block.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Acked-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      84bd21a7
    • NeilBrown's avatar
      blk: Ensure users for current->bio_list can see the full list. · 5cca175b
      NeilBrown authored
      commit f5fe1b51 upstream.
      
      Commit 79bd9959 ("blk: improve order of bio handling in generic_make_request()")
      changed current->bio_list so that it did not contain *all* of the
      queued bios, but only those submitted by the currently running
      make_request_fn.
      
      There are two places which walk the list and requeue selected bios,
      and others that check if the list is empty.  These are no longer
      correct.
      
      So redefine current->bio_list to point to an array of two lists, which
      contain all queued bios, and adjust various code to test or walk both
      lists.
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Fixes: 79bd9959 ("blk: improve order of bio handling in generic_make_request()")
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      [jwang: backport to 4.4]
      Signed-off-by: default avatarJack Wang <jinpu.wang@profitbricks.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Restore changes in device-mapper from upstream version]
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      5cca175b
    • NeilBrown's avatar
      blk: improve order of bio handling in generic_make_request() · 2cbd78f4
      NeilBrown authored
      commit 79bd9959 upstream.
      
      To avoid recursion on the kernel stack when stacked block devices
      are in use, generic_make_request() will, when called recursively,
      queue new requests for later handling.  They will be handled when the
      make_request_fn for the current bio completes.
      
      If any bios are submitted by a make_request_fn, these will ultimately
      be handled seqeuntially.  If the handling of one of those generates
      further requests, they will be added to the end of the queue.
      
      This strict first-in-first-out behaviour can lead to deadlocks in
      various ways, normally because a request might need to wait for a
      previous request to the same device to complete.  This can happen when
      they share a mempool, and can happen due to interdependencies
      particular to the device.  Both md and dm have examples where this happens.
      
      These deadlocks can be erradicated by more selective ordering of bios.
      Specifically by handling them in depth-first order.  That is: when the
      handling of one bio generates one or more further bios, they are
      handled immediately after the parent, before any siblings of the
      parent.  That way, when generic_make_request() calls make_request_fn
      for some particular device, we can be certain that all previously
      submited requests for that device have been completely handled and are
      not waiting for anything in the queue of requests maintained in
      generic_make_request().
      
      An easy way to achieve this would be to use a last-in-first-out stack
      instead of a queue.  However this will change the order of consecutive
      bios submitted by a make_request_fn, which could have unexpected consequences.
      Instead we take a slightly more complex approach.
      A fresh queue is created for each call to a make_request_fn.  After it completes,
      any bios for a different device are placed on the front of the main queue, followed
      by any bios for the same device, followed by all bios that were already on
      the queue before the make_request_fn was called.
      This provides the depth-first approach without reordering bios on the same level.
      
      This, by itself, it not enough to remove all deadlocks.  It just makes
      it possible for drivers to take the extra step required themselves.
      
      To avoid deadlocks, drivers must never risk waiting for a request
      after submitting one to generic_make_request.  This includes never
      allocing from a mempool twice in the one call to a make_request_fn.
      
      A common pattern in drivers is to call bio_split() in a loop, handling
      the first part and then looping around to possibly split the next part.
      Instead, a driver that finds it needs to split a bio should queue
      (with generic_make_request) the second part, handle the first part,
      and then return.  The new code in generic_make_request will ensure the
      requests to underlying bios are processed first, then the second bio
      that was split off.  If it splits again, the same process happens.  In
      each case one bio will be completely handled before the next one is attempted.
      
      With this is place, it should be possible to disable the
      punt_bios_to_recover() recovery thread for many block devices, and
      eventually it may be possible to remove it completely.
      
      Ref: http://www.spinics.net/lists/raid/msg54680.htmlTested-by: default avatarJinpu Wang <jinpu.wang@profitbricks.com>
      Inspired-by: default avatarLars Ellenberg <lars.ellenberg@linbit.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      [jwang: backport to 4.4]
      Signed-off-by: default avatarJack Wang <jinpu.wang@profitbricks.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2cbd78f4
    • Alexandre Belloni's avatar
      power: reset: at91-poweroff: timely shutdown LPDDR memories · 063d30f1
      Alexandre Belloni authored
      commit 0b040874 upstream.
      
      LPDDR memories can only handle up to 400 uncontrolled power off. Ensure the
      proper power off sequence is used before shutting down the platform.
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      063d30f1
    • David Hildenbrand's avatar
      KVM: kvm_io_bus_unregister_dev() should never fail · 42462d23
      David Hildenbrand authored
      commit 90db1043 upstream.
      
      No caller currently checks the return value of
      kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on
      freeing their device. A stale reference will remain in the io_bus,
      getting at least used again, when the iobus gets teared down on
      kvm_destroy_vm() - leading to use after free errors.
      
      There is nothing the callers could do, except retrying over and over
      again.
      
      So let's simply remove the bus altogether, print an error and make
      sure no one can access this broken bus again (returning -ENOMEM on any
      attempt to access it).
      
      Fixes: e93f8a0f ("KVM: convert io_bus to SRCU")
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Reviewed-by: default avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      42462d23
    • Uwe Kleine-König's avatar
      rtc: s35390a: improve irq handling · 3a1246b4
      Uwe Kleine-König authored
      commit 3bd32722 upstream.
      
      On some QNAP NAS devices the rtc can wake the machine. Several people
      noticed that once the machine was woken this way it fails to shut down.
      That's because the driver fails to acknowledge the interrupt and so it
      keeps active and restarts the machine immediatly after shutdown. See
      https://bugs.debian.org/794266 for a bug report.
      
      Doing this correctly requires to interpret the INT2 flag of the first read
      of the STATUS1 register because this bit is cleared by read.
      
      Note this is not maximally robust though because a pending irq isn't
      detected when the STATUS1 register was already read (and so INT2 is not
      set) but the irq was not disabled. But that is a hardware imposed problem
      that cannot easily be fixed by software.
      Signed-off-by: default avatarUwe Kleine-König <uwe@kleine-koenig.org>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3a1246b4
    • Uwe Kleine-König's avatar
      rtc: s35390a: implement reset routine as suggested by the reference · a55ae9d1
      Uwe Kleine-König authored
      commit 8e6583f1 upstream.
      
      There were two deviations from the reference manual: you have to wait
      half a second when POC is active and you might have to repeat
      initialization when POC or BLD are still set after the sequence.
      
      Note however that as POC and BLD are cleared by read the driver might
      not be able to detect that a reset is necessary. I don't have a good
      idea how to fix this.
      
      Additionally report the value read from STATUS1 to the caller. This
      prepares the next patch.
      Signed-off-by: default avatarUwe Kleine-König <uwe@kleine-koenig.org>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a55ae9d1
    • Uwe Kleine-König's avatar
      rtc: s35390a: make sure all members in the output are set · fdd4bc93
      Uwe Kleine-König authored
      The rtc core calls the .read_alarm with all fields initialized to 0. As
      the s35390a driver doesn't touch some fields the returned date is
      interpreted as a date in January 1900. So make sure all fields are set
      to -1; some of them are then overwritten with the right data depending
      on the hardware state.
      
      In mainline this is done by commit d68778b8 ("rtc: initialize output
      parameter for read alarm to "uninitialized"") in the core. This is
      considered to dangerous for stable as it might have side effects for
      other rtc drivers that might for example rely on alarm->time.tm_sec
      being initialized to 0.
      Signed-off-by: default avatarUwe Kleine-König <uwe@kleine-koenig.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fdd4bc93
    • Uwe Kleine-König's avatar
      rtc: s35390a: fix reading out alarm · b3ed3864
      Uwe Kleine-König authored
      commit f87e904d upstream.
      
      There are several issues fixed in this patch:
      
       - When alarm isn't enabled, set .enabled to zero instead of returning
         -EINVAL.
       - Ignore how IRQ1 is configured when determining if IRQ2 is on.
       - The three alarm registers have an enable flag which must be
         evaluated.
       - The chip always triggers when the seconds register gets 0.
      
      Note that the rtc framework however doesn't handle the result correctly
      because it doesn't check wday being initialized and so interprets an
      alarm being set for 10:00 AM in three days as 10:00 AM tomorrow (or
      today if that's not over yet).
      Signed-off-by: default avatarUwe Kleine-König <uwe@kleine-koenig.org>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3ed3864
    • Felix Fietkau's avatar
      MIPS: Lantiq: Fix cascaded IRQ setup · 6280ac93
      Felix Fietkau authored
      commit 6c356eda upstream.
      
      With the IRQ stack changes integrated, the XRX200 devices started
      emitting a constant stream of kernel messages like this:
      
      [  565.415310] Spurious IRQ: CAUSE=0x1100c300
      
      This is caused by IP0 getting handled by plat_irq_dispatch() rather than
      its vectored interrupt handler, which is fixed by commit de856416e714
      ("MIPS: IRQ Stack: Fix erroneous jal to plat_irq_dispatch").
      
      Fix plat_irq_dispatch() to handle non-vectored IPI interrupts correctly
      by setting up IP2-6 as proper chained IRQ handlers and calling do_IRQ
      for all MIPS CPU interrupts.
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Acked-by: default avatarJohn Crispin <john@phrozen.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/15077/
      [james.hogan@imgtec.com: tweaked commit message]
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarAmit Pundir <amit.pundir@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6280ac93
    • Naoya Horiguchi's avatar
      mm, hugetlb: use pte_present() instead of pmd_present() in follow_huge_pmd() · 47e2fe17
      Naoya Horiguchi authored
      commit c9d398fa upstream.
      
      I found the race condition which triggers the following bug when
      move_pages() and soft offline are called on a single hugetlb page
      concurrently.
      
          Soft offlining page 0x119400 at 0x700000000000
          BUG: unable to handle kernel paging request at ffffea0011943820
          IP: follow_huge_pmd+0x143/0x190
          PGD 7ffd2067
          PUD 7ffd1067
          PMD 0
              [61163.582052] Oops: 0000 [#1] SMP
          Modules linked in: binfmt_misc ppdev virtio_balloon parport_pc pcspkr i2c_piix4 parport i2c_core acpi_cpufreq ip_tables xfs libcrc32c ata_generic pata_acpi virtio_blk 8139too crc32c_intel ata_piix serio_raw libata virtio_pci 8139cp virtio_ring virtio mii floppy dm_mirror dm_region_hash dm_log dm_mod [last unloaded: cap_check]
          CPU: 0 PID: 22573 Comm: iterate_numa_mo Tainted: P           OE   4.11.0-rc2-mm1+ #2
          Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
          RIP: 0010:follow_huge_pmd+0x143/0x190
          RSP: 0018:ffffc90004bdbcd0 EFLAGS: 00010202
          RAX: 0000000465003e80 RBX: ffffea0004e34d30 RCX: 00003ffffffff000
          RDX: 0000000011943800 RSI: 0000000000080001 RDI: 0000000465003e80
          RBP: ffffc90004bdbd18 R08: 0000000000000000 R09: ffff880138d34000
          R10: ffffea0004650000 R11: 0000000000c363b0 R12: ffffea0011943800
          R13: ffff8801b8d34000 R14: ffffea0000000000 R15: 000077ff80000000
          FS:  00007fc977710740(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          CR2: ffffea0011943820 CR3: 000000007a746000 CR4: 00000000001406f0
          Call Trace:
           follow_page_mask+0x270/0x550
           SYSC_move_pages+0x4ea/0x8f0
           SyS_move_pages+0xe/0x10
           do_syscall_64+0x67/0x180
           entry_SYSCALL64_slow_path+0x25/0x25
          RIP: 0033:0x7fc976e03949
          RSP: 002b:00007ffe72221d88 EFLAGS: 00000246 ORIG_RAX: 0000000000000117
          RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc976e03949
          RDX: 0000000000c22390 RSI: 0000000000001400 RDI: 0000000000005827
          RBP: 00007ffe72221e00 R08: 0000000000c2c3a0 R09: 0000000000000004
          R10: 0000000000c363b0 R11: 0000000000000246 R12: 0000000000400650
          R13: 00007ffe72221ee0 R14: 0000000000000000 R15: 0000000000000000
          Code: 81 e4 ff ff 1f 00 48 21 c2 49 c1 ec 0c 48 c1 ea 0c 4c 01 e2 49 bc 00 00 00 00 00 ea ff ff 48 c1 e2 06 49 01 d4 f6 45 bc 04 74 90 <49> 8b 7c 24 20 40 f6 c7 01 75 2b 4c 89 e7 8b 47 1c 85 c0 7e 2a
          RIP: follow_huge_pmd+0x143/0x190 RSP: ffffc90004bdbcd0
          CR2: ffffea0011943820
          ---[ end trace e4f81353a2d23232 ]---
          Kernel panic - not syncing: Fatal exception
          Kernel Offset: disabled
      
      This bug is triggered when pmd_present() returns true for non-present
      hugetlb, so fixing the present check in follow_huge_pmd() prevents it.
      Using pmd_present() to determine present/non-present for hugetlb is not
      correct, because pmd_present() checks multiple bits (not only
      _PAGE_PRESENT) for historical reason and it can misjudge hugetlb state.
      
      Fixes: e66f17ff ("mm/hugetlb: take page table lock in follow_huge_pmd()")
      Link: http://lkml.kernel.org/r/1490149898-20231-1-git-send-email-n-horiguchi@ah.jp.nec.comSigned-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: default avatarHillf Danton <hillf.zj@alibaba-inc.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47e2fe17
    • Michel Dänzer's avatar
      drm/radeon: Override fpfn for all VRAM placements in radeon_evict_flags · ef55c3df
      Michel Dänzer authored
      commit ce4b4f22 upstream.
      
      We were accidentally only overriding the first VRAM placement. For BOs
      with the RADEON_GEM_NO_CPU_ACCESS flag set,
      radeon_ttm_placement_from_domain creates a second VRAM placment with
      fpfn == 0. If VRAM is almost full, the first VRAM placement with
      fpfn > 0 may not work, but the second one with fpfn == 0 always will
      (the BO's current location trivially satisfies it). Because "moving"
      the BO to its current location puts it back on the LRU list, this
      results in an infinite loop.
      
      Fixes: 2a85aedd ("drm/radeon: Try evicting from CPU accessible to
                            inaccessible VRAM first")
      Reported-by: default avatarZachary Michaels <zmichaels@oblong.com>
      Reported-and-Tested-by: default avatarJulien Isorce <jisorce@oblong.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ef55c3df
    • Peter Xu's avatar
      KVM: x86: clear bus pointer when destroyed · 3eb39205
      Peter Xu authored
      commit df630b8c upstream.
      
      When releasing the bus, let's clear the bus pointers to mark it out. If
      any further device unregister happens on this bus, we know that we're
      done if we found the bus being released already.
      Signed-off-by: default avatarPeter Xu <peterx@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3eb39205
    • Alan Stern's avatar
      USB: fix linked-list corruption in rh_call_control() · eac3ab3e
      Alan Stern authored
      commit 16336820 upstream.
      
      Using KASAN, Dmitry found a bug in the rh_call_control() routine: If
      buffer allocation fails, the routine returns immediately without
      unlinking its URB from the control endpoint, eventually leading to
      linked-list corruption.
      
      This patch fixes the problem by jumping to the end of the routine
      (where the URB is unlinked) when an allocation failure occurs.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-and-tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eac3ab3e
    • Nicolas Ferre's avatar
      tty/serial: atmel: fix TX path in atmel_console_write() · 0a1757cf
      Nicolas Ferre authored
      commit 497e1e16 upstream.
      
      A side effect of 89d82324 ("tty/serial: atmel_serial: BUG: stop DMA
      from transmitting in stop_tx") is that the console can be called with
      TX path disabled. Then the system would hang trying to push charecters
      out in atmel_console_putchar().
      Signed-off-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Fixes: 89d82324 ("tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a1757cf
    • Richard Genoud's avatar
      tty/serial: atmel: fix race condition (TX+DMA) · 74b8fc01
      Richard Genoud authored
      commit 31ca2c63 upstream.
      
      If uart_flush_buffer() is called between atmel_tx_dma() and
      atmel_complete_tx_dma(), the circular buffer has been cleared, but not
      atmel_port->tx_len.
      That leads to a circular buffer overflow (dumping (UART_XMIT_SIZE -
      atmel_port->tx_len) bytes).
      Tested-by: default avatarNicolas Ferre <nicolas.ferre@microchip.com>
      Signed-off-by: default avatarRichard Genoud <richard.genoud@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      74b8fc01
    • Joerg Roedel's avatar
      ACPI: Do not create a platform_device for IOAPIC/IOxAPIC · 566a8711
      Joerg Roedel authored
      commit 08f63d97 upstream.
      
      No platform-device is required for IO(x)APICs, so don't even
      create them.
      
      [ rjw: This fixes a problem with leaking platform device objects
        after IOAPIC/IOxAPIC hot-removal events.]
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      566a8711