1. 03 Mar, 2016 40 commits
    • Thomas Gleixner's avatar
      x86/irq: Remove offline cpus from vector cleanup · 550ac3f7
      Thomas Gleixner authored
      commit 847667ef upstream.
      
      No point of keeping offline cpus in the cleanup mask.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Jeremiah Mahler <jmmahler@gmail.com>
      Cc: andy.shevchenko@gmail.com
      Cc: Guenter Roeck <linux@roeck-us.net>
      Link: http://lkml.kernel.org/r/20151231160106.808642683@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      550ac3f7
    • Thomas Gleixner's avatar
      x86/irq: Get rid of code duplication · c655fd01
      Thomas Gleixner authored
      commit ab25ac02 upstream.
      
      Reusing an existing vector and assigning a new vector has duplicated
      code. Consolidate it.
      
      This is also a preparatory patch for finally plugging the cleanup race.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Jeremiah Mahler <jmmahler@gmail.com>
      Cc: andy.shevchenko@gmail.com
      Cc: Guenter Roeck <linux@roeck-us.net>
      Link: http://lkml.kernel.org/r/20151231160106.721599216@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c655fd01
    • Thomas Gleixner's avatar
      x86/irq: Copy vectormask instead of an AND operation · 2636de2f
      Thomas Gleixner authored
      commit 9ac15b7a upstream.
      
      In the case that the new vector mask is a subset of the existing mask there is
      no point to do a AND operation of currentmask & newmask. The result is
      newmask. So we can simply copy the new mask to the current mask and be done
      with it. Preparatory patch for further consolidation.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Jeremiah Mahler <jmmahler@gmail.com>
      Cc: andy.shevchenko@gmail.com
      Cc: Guenter Roeck <linux@roeck-us.net>
      Link: http://lkml.kernel.org/r/20151231160106.640253454@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2636de2f
    • Thomas Gleixner's avatar
      x86/irq: Check vector allocation early · 4af6a215
      Thomas Gleixner authored
      commit 3716fd27 upstream.
      
      __assign_irq_vector() uses the vector_cpumask which is assigned by
      apic->vector_allocation_domain() without doing basic sanity checks. That can
      result in a situation where the final assignement of a newly found vector
      fails in apic->cpu_mask_to_apicid_and(). So we have to do rollbacks for no
      reason.
      
      apic->cpu_mask_to_apicid_and() only fails if
      
        vector_cpumask & requested_cpumask & cpu_online_mask
      
      is empty.
      
      Check for this condition right away and if the result is empty try immediately
      the next possible cpu in the requested mask. So in case of a failure the old
      setting is unchanged and we can remove the rollback code.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Jeremiah Mahler <jmmahler@gmail.com>
      Cc: andy.shevchenko@gmail.com
      Cc: Guenter Roeck <linux@roeck-us.net>
      Link: http://lkml.kernel.org/r/20151231160106.561877324@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4af6a215
    • Thomas Gleixner's avatar
      x86/irq: Reorganize the search in assign_irq_vector · cb987d48
      Thomas Gleixner authored
      commit 95ffeb4b upstream.
      
      Split out the code which advances the target cpu for the search so we can
      reuse it for the next patch which adds an early validation check for the
      vectormask which we get from the apic.
      
      Add comments while at it.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Jeremiah Mahler <jmmahler@gmail.com>
      Cc: andy.shevchenko@gmail.com
      Cc: Guenter Roeck <linux@roeck-us.net>
      Link: http://lkml.kernel.org/r/20151231160106.484562040@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cb987d48
    • Thomas Gleixner's avatar
      x86/irq: Reorganize the return path in assign_irq_vector · f6e9ce2b
      Thomas Gleixner authored
      commit 433cbd57 upstream.
      
      Use an explicit goto for the cases where we have success in the search/update
      and return -ENOSPC if the search loop ends due to no space.
      
      Preparatory patch for fixes. No functional change.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Jeremiah Mahler <jmmahler@gmail.com>
      Cc: andy.shevchenko@gmail.com
      Cc: Guenter Roeck <linux@roeck-us.net>
      Link: http://lkml.kernel.org/r/20151231160106.403491024@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f6e9ce2b
    • Jiang Liu's avatar
      x86/irq: Do not use apic_chip_data.old_domain as temporary buffer · cf2e82af
      Jiang Liu authored
      commit 8a580f70 upstream.
      
      Function __assign_irq_vector() makes use of apic_chip_data.old_domain as a
      temporary buffer, which is in the way of using apic_chip_data.old_domain for
      synchronizing the vector cleanup with the vector assignement code.
      
      Use a proper temporary cpumask for this.
      
      [ tglx: Renamed the mask to searched_cpumask for clarity ]
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Cc: Jeremiah Mahler <jmmahler@gmail.com>
      Cc: andy.shevchenko@gmail.com
      Cc: Guenter Roeck <linux@roeck-us.net>
      Link: http://lkml.kernel.org/r/1450880014-11741-1-git-send-email-jiang.liu@linux.intel.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf2e82af
    • Thomas Gleixner's avatar
      x86/irq: Validate that irq descriptor is still active · 053c8ecc
      Thomas Gleixner authored
      commit 36f34c8c upstream.
      
      In fixup_irqs() we unconditionally dereference the irq chip of an irq
      descriptor. The descriptor might still be valid, but already cleaned up,
      i.e. the chip removed. Add a check for this condition.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Joe Lawrence <joe.lawrence@stratus.com>
      Cc: Jeremiah Mahler <jmmahler@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: andy.shevchenko@gmail.com
      Cc: Guenter Roeck <linux@roeck-us.net>
      Link: http://lkml.kernel.org/r/20151231160106.236423282@linutronix.deSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      053c8ecc
    • Jiang Liu's avatar
      x86/irq: Fix a race in x86_vector_free_irqs() · e4d1544b
      Jiang Liu authored
      commit 111abeba upstream.
      
      There's a race condition between
      
      x86_vector_free_irqs()
      {
      	free_apic_chip_data(irq_data->chip_data);
      	xxxxx	//irq_data->chip_data has been freed, but the pointer
      		//hasn't been reset yet
      	irq_domain_reset_irq_data(irq_data);
      }
      
      and
      
      smp_irq_move_cleanup_interrupt()
      {
      	raw_spin_lock(&vector_lock);
      	data = apic_chip_data(irq_desc_get_irq_data(desc));
      	access data->xxxx	// may access freed memory
      	raw_spin_unlock(&desc->lock);
      }
      
      which may cause smp_irq_move_cleanup_interrupt() to access freed memory.
      
      Call irq_domain_reset_irq_data(), which clears the pointer with vector lock
      held.
      
      [ tglx: Free memory outside of lock held region. ]
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Cc: Jeremiah Mahler <jmmahler@gmail.com>
      Cc: andy.shevchenko@gmail.com
      Cc: Guenter Roeck <linux@roeck-us.net>
      Link: http://lkml.kernel.org/r/1450880014-11741-3-git-send-email-jiang.liu@linux.intel.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e4d1544b
    • Thomas Gleixner's avatar
      x86/irq: Call chip->irq_set_affinity in proper context · 7df19ad4
      Thomas Gleixner authored
      commit e23b257c upstream.
      
      setup_ioapic_dest() calls irqchip->irq_set_affinity() completely
      unprotected. That's wrong in several aspects:
      
       - it opens a race window where irq_set_affinity() can be interrupted and the
         irq chip left in unconsistent state.
      
       - it triggers a lockdep splat when we fix the vector race for 4.3+ because
         vector lock is taken with interrupts enabled.
      
      The proper calling convention is irq descriptor lock held and interrupts
      disabled.
      Reported-and-tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Jeremiah Mahler <jmmahler@gmail.com>
      Cc: andy.shevchenko@gmail.com
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Joe Lawrence <joe.lawrence@stratus.com>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1601140919420.3575@nanosSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7df19ad4
    • Andy Lutomirski's avatar
      x86/entry/compat: Add missing CLAC to entry_INT80_32 · eeb241d4
      Andy Lutomirski authored
      commit 3d44d51b upstream.
      
      This doesn't seem to fix a regression -- I don't think the CLAC was
      ever there.
      
      I double-checked in a debugger: entries through the int80 gate do
      not automatically clear AC.
      
      Stable maintainers: I can provide a backport to 4.3 and earlier if
      needed.  This needs to be backported all the way to 3.10.
      Reported-by: default avatarBrian Gerst <brgerst@gmail.com>
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 63bcff2a ("x86, smap: Add STAC and CLAC instructions to control user space access")
      Link: http://lkml.kernel.org/r/b02b7e71ae54074be01fc171cbd4b72517055c0e.1456345086.git.luto@kernel.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eeb241d4
    • Colin Ian King's avatar
      x86/mpx: Fix off-by-one comparison with nr_registers · 04100683
      Colin Ian King authored
      commit 9bf148cb upstream.
      
      In the unlikely event that regno == nr_registers then we get an array
      overrun on regoff because the invalid register check is currently
      off-by-one. Fix this with a check that regno is >= nr_registers instead.
      
      Detected with static analysis using CoverityScan.
      
      Fixes: fcc7ffd6 "x86, mpx: Decode MPX instruction to get bound violation information"
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Acked-by: default avatarDave Hansen <dave.hansen@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
      Link: http://lkml.kernel.org/r/1456512931-3388-1-git-send-email-colin.king@canonical.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04100683
    • Mikulas Patocka's avatar
      hpfs: don't truncate the file when delete fails · 04d94690
      Mikulas Patocka authored
      commit b6853f78 upstream.
      
      The delete opration can allocate additional space on the HPFS filesystem
      due to btree split. The HPFS driver checks in advance if there is
      available space, so that it won't corrupt the btree if we run out of space
      during splitting.
      
      If there is not enough available space, the HPFS driver attempted to
      truncate the file, but this results in a deadlock since the commit
      7dd29d8d ("HPFS: Introduce a global mutex
      and lock it on every callback from VFS").
      
      This patch removes the code that tries to truncate the file and -ENOSPC is
      returned instead. If the user hits -ENOSPC on delete, he should try to
      delete other files (that are stored in a leaf btree node), so that the
      delete operation will make some space for deleting the file stored in
      non-leaf btree node.
      Reported-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: default avatarMikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04d94690
    • Al Viro's avatar
      do_last(): ELOOP failure exit should be done after leaving RCU mode · d57c0477
      Al Viro authored
      commit 5129fa48 upstream.
      
      ... or we risk seeing a bogus value of d_is_symlink() there.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d57c0477
    • Al Viro's avatar
      should_follow_link(): validate ->d_seq after having decided to follow · 6f4b352f
      Al Viro authored
      commit a7f77542 upstream.
      
      ... otherwise d_is_symlink() above might have nothing to do with
      the inode value we've got.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f4b352f
    • Konrad Rzeszutek Wilk's avatar
      xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted. · 9108b130
      Konrad Rzeszutek Wilk authored
      commit 4d8c8bd6 upstream.
      
      Occasionaly PV guests would crash with:
      
      pciback 0000:00:00.1: Xen PCI mapped GSI0 to IRQ16
      BUG: unable to handle kernel paging request at 0000000d1a8c0be0
      .. snip..
        <ffffffff8139ce1b>] find_next_bit+0xb/0x10
        [<ffffffff81387f22>] cpumask_next_and+0x22/0x40
        [<ffffffff813c1ef8>] pci_device_probe+0xb8/0x120
        [<ffffffff81529097>] ? driver_sysfs_add+0x77/0xa0
        [<ffffffff815293e4>] driver_probe_device+0x1a4/0x2d0
        [<ffffffff813c1ddd>] ? pci_match_device+0xdd/0x110
        [<ffffffff81529657>] __device_attach_driver+0xa7/0xb0
        [<ffffffff815295b0>] ? __driver_attach+0xa0/0xa0
        [<ffffffff81527622>] bus_for_each_drv+0x62/0x90
        [<ffffffff8152978d>] __device_attach+0xbd/0x110
        [<ffffffff815297fb>] device_attach+0xb/0x10
        [<ffffffff813b75ac>] pci_bus_add_device+0x3c/0x70
        [<ffffffff813b7618>] pci_bus_add_devices+0x38/0x80
        [<ffffffff813dc34e>] pcifront_scan_root+0x13e/0x1a0
        [<ffffffff817a0692>] pcifront_backend_changed+0x262/0x60b
        [<ffffffff814644c6>] ? xenbus_gather+0xd6/0x160
        [<ffffffff8120900f>] ? put_object+0x2f/0x50
        [<ffffffff81465c1d>] xenbus_otherend_changed+0x9d/0xa0
        [<ffffffff814678ee>] backend_changed+0xe/0x10
        [<ffffffff81463a28>] xenwatch_thread+0xc8/0x190
        [<ffffffff810f22f0>] ? woken_wake_function+0x10/0x10
      
      which was the result of two things:
      
      When we call pci_scan_root_bus we would pass in 'sd' (sysdata)
      pointer which was an 'pcifront_sd' structure. However in the
      pci_device_add it expects that the 'sd' is 'struct sysdata' and
      sets the dev->node to what is in sd->node (offset 4):
      
      set_dev_node(&dev->dev, pcibus_to_node(bus));
      
       __pcibus_to_node(const struct pci_bus *bus)
      {
              const struct pci_sysdata *sd = bus->sysdata;
      
              return sd->node;
      }
      
      However our structure was pcifront_sd which had nothing at that
      offset:
      
      struct pcifront_sd {
              int                        domain;    /*     0     4 */
              /* XXX 4 bytes hole, try to pack */
              struct pcifront_device *   pdev;      /*     8     8 */
      }
      
      That is an hole - filled with garbage as we used kmalloc instead of
      kzalloc (the second problem).
      
      This patch fixes the issue by:
       1) Use kzalloc to initialize to a well known state.
       2) Put 'struct pci_sysdata' at the start of 'pcifront_sd'. That
          way access to the 'node' will access the right offset.
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9108b130
    • Konrad Rzeszutek Wilk's avatar
      xen/pciback: Save the number of MSI-X entries to be copied later. · 4cf5aa2f
      Konrad Rzeszutek Wilk authored
      commit d159457b upstream.
      
      Commit 8135cf8b (xen/pciback: Save
      xen_pci_op commands before processing it) broke enabling MSI-X because
      it would never copy the resulting vectors into the response.  The
      number of vectors requested was being overwritten by the return value
      (typically zero for success).
      
      Save the number of vectors before processing the op, so the correct
      number of vectors are copied afterwards.
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4cf5aa2f
    • Konrad Rzeszutek Wilk's avatar
      xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORY · d52a2481
      Konrad Rzeszutek Wilk authored
      commit 8d47065f upstream.
      
      Commit 408fb0e5 (xen/pciback: Don't
      allow MSI-X ops if PCI_COMMAND_MEMORY is not set) prevented enabling
      MSI-X on passed-through virtual functions, because it checked the VF
      for PCI_COMMAND_MEMORY but this is not a valid bit for VFs.
      
      Instead, check the physical function for PCI_COMMAND_MEMORY.
      Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d52a2481
    • Juergen Gross's avatar
      xen/scsiback: correct frontend counting · e32b123f
      Juergen Gross authored
      commit f285aa8d upstream.
      
      When adding a new frontend to xen-scsiback don't decrement the number
      of active frontends in case of no error. Doing so results in a failure
      when trying to remove the xen-pvscsi nexus even if no domain is using
      it.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e32b123f
    • Ian Campbell's avatar
      xen/arm: correctly handle DMA mapping of compound pages · 392abe33
      Ian Campbell authored
      commit 52ba0746 upstream.
      
      Currently xen_dma_map_page concludes that DMA to anything other than
      the head page of a compound page must be foreign, since the PFN of the
      page is that of the head.
      
      Fix the check to instead consider the whole of a compound page to be
      local if the PFN of the head passes the 1:1 check.
      
      We can never see a compound page which is a mixture of foreign and
      local sub-pages.
      
      The comment already correctly described the intention, but fixup the
      spelling and some grammar.
      
      This fixes the various SSH protocol errors which we have been seeing
      on the cubietrucks in our automated test infrastructure.
      
      This has been broken since commit 3567258d ("xen/arm: use
      hypercall to flush caches in map_page"), which was in v3.19-rc1.
      
      NB arch/arm64/.../xen/page-coherent.h also includes this file.
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Reviewed-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Cc: xen-devel@lists.xenproject.org
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      392abe33
    • Ludovic Desroches's avatar
      ARM: at91/dt: fix typo in sama5d2 pinmux descriptions · 362decca
      Ludovic Desroches authored
      commit 5e45a258 upstream.
      
      PIN_PA15 macro has the same value as PIN_PA14 so we were overriding PA14
      mux/configuration.
      Signed-off-by: default avatarLudovic Desroches <ludovic.desroches@atmel.com>
      Reported-by: default avatarCyrille Pitchen <cyrille.pitchen@atmel.com>
      Fixes: 7f16cb67 ("ARM: at91/dt: add sama5d2 pinmux")
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@free-electrons.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      362decca
    • Ivaylo Dimitrov's avatar
      ARM: OMAP2+: Fix onenand initialization to avoid filesystem corruption · 8b78924f
      Ivaylo Dimitrov authored
      commit 3f315c5b upstream.
      
      Commit e7b11dc7 ("ARM: OMAP2+: Fix onenand rate detection to avoid
      filesystem corruption") partially fixed onenand configuration when GPMC
      module is reset. Finish the job by also providing the correct values in
      ONENAND_REG_SYS_CFG1 register.
      
      Fixes: e7b11dc7 ("ARM: OMAP2+: Fix onenand rate detection to avoid
      filesystem corruption")
      Signed-off-by: default avatarIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
      Tested-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8b78924f
    • Al Viro's avatar
      do_last(): don't let a bogus return value from ->open() et.al. to confuse us · 80d18c00
      Al Viro authored
      commit c80567c8 upstream.
      
      ... into returning a positive to path_openat(), which would interpret that
      as "symlink had been encountered" and proceed to corrupt memory, etc.
      It can only happen due to a bug in some ->open() instance or in some LSM
      hook, etc., so we report any such event *and* make sure it doesn't trick
      us into further unpleasantness.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80d18c00
    • Simon Guinot's avatar
      kernel/resource.c: fix muxed resource handling in __request_region() · f634ac98
      Simon Guinot authored
      commit 59ceeaaf upstream.
      
      In __request_region, if a conflict with a BUSY and MUXED resource is
      detected, then the caller goes to sleep and waits for the resource to be
      released.  A pointer on the conflicting resource is kept.  At wake-up
      this pointer is used as a parent to retry to request the region.
      
      A first problem is that this pointer might well be invalid (if for
      example the conflicting resource have already been freed).  Another
      problem is that the next call to __request_region() fails to detect a
      remaining conflict.  The previously conflicting resource is passed as a
      parameter and __request_region() will look for a conflict among the
      children of this resource and not at the resource itself.  It is likely
      to succeed anyway, even if there is still a conflict.
      
      Instead, the parent of the conflicting resource should be passed to
      __request_region().
      
      As a fix, this patch doesn't update the parent resource pointer in the
      case we have to wait for a muxed region right after.
      Reported-and-tested-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Signed-off-by: default avatarSimon Guinot <simon.guinot@sequanux.org>
      Tested-by: default avatarVincent Donnefort <vdonnefort@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f634ac98
    • Stefan Hajnoczi's avatar
      sunrpc/cache: fix off-by-one in qword_get() · dc16b439
      Stefan Hajnoczi authored
      commit b7052cd7 upstream.
      
      The qword_get() function NUL-terminates its output buffer.  If the input
      string is in hex format \xXXXX... and the same length as the output
      buffer, there is an off-by-one:
      
        int qword_get(char **bpp, char *dest, int bufsize)
        {
            ...
            while (len < bufsize) {
                ...
                *dest++ = (h << 4) | l;
                len++;
            }
            ...
            *dest = '\0';
            return len;
        }
      
      This patch ensures the NUL terminator doesn't fall outside the output
      buffer.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc16b439
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Fix showing function event in available_events · 36b53e8b
      Steven Rostedt (Red Hat) authored
      commit d045437a upstream.
      
      The ftrace:function event is only displayed for parsing the function tracer
      data. It is not used to enable function tracing, and does not include an
      "enable" file in its event directory.
      
      Originally, this event was kept separate from other events because it did
      not have a ->reg parameter. But perf added a "reg" parameter for its use
      which caused issues, because it made the event available to functions where
      it was not compatible for.
      
      Commit 9b63776f "tracing: Do not enable function event with enable"
      added a TRACE_EVENT_FL_IGNORE_ENABLE flag that prevented the function event
      from being enabled by normal trace events. But this commit missed keeping
      the function event from being displayed by the "available_events" directory,
      which is used to show what events can be enabled by set_event.
      
      One documented way to enable all events is to:
      
       cat available_events > set_event
      
      But because the function event is displayed in the available_events, this
      now causes an INVALID error:
      
       cat: write error: Invalid argument
      Reported-by: default avatarChunyu Hu <chuhu@redhat.com>
      Fixes: 9b63776f "tracing: Do not enable function event with enable"
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36b53e8b
    • Gavin Shan's avatar
      powerpc/eeh: Fix partial hotplug criterion · 222473f7
      Gavin Shan authored
      commit f6bf0fa1 upstream.
      
      During error recovery, the device could be removed as part of the
      partial hotplug. The criterion used to come with partial hotplug
      is: if the device driver provides error_detected(), slot_reset()
      and resume() callbacks, it's immune from hotplug. Otherwise,
      it's going to experience partial hotplug during EEH recovery. But
      the criterion isn't correct enough: mlx4_core driver for Mellanox
      adapters provides error_detected(), slot_reset() callbacks, but
      resume() isn't there. Those Mellanox adapters won't be to involved
      in the partial hotplug.
      
      This fixes the criterion to a practical one: adpater with driver
      that provides error_detected(), slot_reset() will be immune from
      partial hotplug. resume() isn't mandatory.
      
      Fixes: f2da4ccf ("powerpc/eeh: More relaxed hotplug criterion")
      Signed-off-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      222473f7
    • Mike Krinkin's avatar
      KVM: x86: MMU: fix ubsan index-out-of-range warning · 4aa584e4
      Mike Krinkin authored
      commit 17e4bce0 upstream.
      
      Ubsan reports the following warning due to a typo in
      update_accessed_dirty_bits template, the patch fixes
      the typo:
      
      [  168.791851] ================================================================================
      [  168.791862] UBSAN: Undefined behaviour in arch/x86/kvm/paging_tmpl.h:252:15
      [  168.791866] index 4 is out of range for type 'u64 [4]'
      [  168.791871] CPU: 0 PID: 2950 Comm: qemu-system-x86 Tainted: G           O L  4.5.0-rc5-next-20160222 #7
      [  168.791873] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
      [  168.791876]  0000000000000000 ffff8801cfcaf208 ffffffff81c9f780 0000000041b58ab3
      [  168.791882]  ffffffff82eb2cc1 ffffffff81c9f6b4 ffff8801cfcaf230 ffff8801cfcaf1e0
      [  168.791886]  0000000000000004 0000000000000001 0000000000000000 ffffffffa1981600
      [  168.791891] Call Trace:
      [  168.791899]  [<ffffffff81c9f780>] dump_stack+0xcc/0x12c
      [  168.791904]  [<ffffffff81c9f6b4>] ? _atomic_dec_and_lock+0xc4/0xc4
      [  168.791910]  [<ffffffff81da9e81>] ubsan_epilogue+0xd/0x8a
      [  168.791914]  [<ffffffff81daafa2>] __ubsan_handle_out_of_bounds+0x15c/0x1a3
      [  168.791918]  [<ffffffff81daae46>] ? __ubsan_handle_shift_out_of_bounds+0x2bd/0x2bd
      [  168.791922]  [<ffffffff811287ef>] ? get_user_pages_fast+0x2bf/0x360
      [  168.791954]  [<ffffffffa1794050>] ? kvm_largepages_enabled+0x30/0x30 [kvm]
      [  168.791958]  [<ffffffff81128530>] ? __get_user_pages_fast+0x360/0x360
      [  168.791987]  [<ffffffffa181b818>] paging64_walk_addr_generic+0x1b28/0x2600 [kvm]
      [  168.792014]  [<ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm]
      [  168.792019]  [<ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350
      [  168.792044]  [<ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm]
      [  168.792076]  [<ffffffffa181c36d>] paging64_gva_to_gpa+0x7d/0x110 [kvm]
      [  168.792121]  [<ffffffffa181c2f0>] ? paging64_walk_addr_generic+0x2600/0x2600 [kvm]
      [  168.792130]  [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
      [  168.792178]  [<ffffffffa17d9a4a>] emulator_read_write_onepage+0x27a/0x1150 [kvm]
      [  168.792208]  [<ffffffffa1794d44>] ? __kvm_read_guest_page+0x54/0x70 [kvm]
      [  168.792234]  [<ffffffffa17d97d0>] ? kvm_task_switch+0x160/0x160 [kvm]
      [  168.792238]  [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
      [  168.792263]  [<ffffffffa17daa07>] emulator_read_write+0xe7/0x6d0 [kvm]
      [  168.792290]  [<ffffffffa183b620>] ? em_cr_write+0x230/0x230 [kvm]
      [  168.792314]  [<ffffffffa17db005>] emulator_write_emulated+0x15/0x20 [kvm]
      [  168.792340]  [<ffffffffa18465f8>] segmented_write+0xf8/0x130 [kvm]
      [  168.792367]  [<ffffffffa1846500>] ? em_lgdt+0x20/0x20 [kvm]
      [  168.792374]  [<ffffffffa14db512>] ? vmx_read_guest_seg_ar+0x42/0x1e0 [kvm_intel]
      [  168.792400]  [<ffffffffa1846d82>] writeback+0x3f2/0x700 [kvm]
      [  168.792424]  [<ffffffffa1846990>] ? em_sidt+0xa0/0xa0 [kvm]
      [  168.792449]  [<ffffffffa185554d>] ? x86_decode_insn+0x1b3d/0x4f70 [kvm]
      [  168.792474]  [<ffffffffa1859032>] x86_emulate_insn+0x572/0x3010 [kvm]
      [  168.792499]  [<ffffffffa17e71dd>] x86_emulate_instruction+0x3bd/0x2110 [kvm]
      [  168.792524]  [<ffffffffa17e6e20>] ? reexecute_instruction.part.110+0x2e0/0x2e0 [kvm]
      [  168.792532]  [<ffffffffa14e9a81>] handle_ept_misconfig+0x61/0x460 [kvm_intel]
      [  168.792539]  [<ffffffffa14e9a20>] ? handle_pause+0x450/0x450 [kvm_intel]
      [  168.792546]  [<ffffffffa15130ea>] vmx_handle_exit+0xd6a/0x1ad0 [kvm_intel]
      [  168.792572]  [<ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm]
      [  168.792597]  [<ffffffffa17f6bcd>] kvm_arch_vcpu_ioctl_run+0xd3d/0x6090 [kvm]
      [  168.792621]  [<ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm]
      [  168.792627]  [<ffffffff8293b530>] ? __ww_mutex_lock_interruptible+0x1630/0x1630
      [  168.792651]  [<ffffffffa17f5e90>] ? kvm_arch_vcpu_runnable+0x4f0/0x4f0 [kvm]
      [  168.792656]  [<ffffffff811eeb30>] ? preempt_notifier_unregister+0x190/0x190
      [  168.792681]  [<ffffffffa17e0447>] ? kvm_arch_vcpu_load+0x127/0x650 [kvm]
      [  168.792704]  [<ffffffffa178e9a3>] kvm_vcpu_ioctl+0x553/0xda0 [kvm]
      [  168.792727]  [<ffffffffa178e450>] ? vcpu_put+0x40/0x40 [kvm]
      [  168.792732]  [<ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350
      [  168.792735]  [<ffffffff82946087>] ? _raw_spin_unlock+0x27/0x40
      [  168.792740]  [<ffffffff8163a943>] ? handle_mm_fault+0x1673/0x2e40
      [  168.792744]  [<ffffffff8129daa8>] ? trace_hardirqs_on_caller+0x478/0x6c0
      [  168.792747]  [<ffffffff8129dcfd>] ? trace_hardirqs_on+0xd/0x10
      [  168.792751]  [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
      [  168.792756]  [<ffffffff81725a80>] do_vfs_ioctl+0x1b0/0x12b0
      [  168.792759]  [<ffffffff817258d0>] ? ioctl_preallocate+0x210/0x210
      [  168.792763]  [<ffffffff8174aef3>] ? __fget+0x273/0x4a0
      [  168.792766]  [<ffffffff8174acd0>] ? __fget+0x50/0x4a0
      [  168.792770]  [<ffffffff8174b1f6>] ? __fget_light+0x96/0x2b0
      [  168.792773]  [<ffffffff81726bf9>] SyS_ioctl+0x79/0x90
      [  168.792777]  [<ffffffff82946880>] entry_SYSCALL_64_fastpath+0x23/0xc1
      [  168.792780] ================================================================================
      Signed-off-by: default avatarMike Krinkin <krinkin.m.u@gmail.com>
      Reviewed-by: default avatarXiao Guangrong <guangrong.xiao@linux.intel.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4aa584e4
    • Paolo Bonzini's avatar
      KVM: x86: fix conversion of addresses to linear in 32-bit protected mode · de5b55f6
      Paolo Bonzini authored
      commit 0c1d77f4 upstream.
      
      Commit e8dd2d2d ("Silence compiler warning in arch/x86/kvm/emulate.c",
      2015-09-06) broke boot of the Hurd.  The bug is that the "default:"
      case actually could modify "la", but after the patch this change is
      not reflected in *linear.
      
      The bug is visible whenever a non-zero segment base causes the linear
      address to wrap around the 4GB mark.
      
      Fixes: e8dd2d2dReported-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      Tested-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de5b55f6
    • Paolo Bonzini's avatar
      KVM: x86: fix missed hardware breakpoints · fc90441e
      Paolo Bonzini authored
      commit 172b2386 upstream.
      
      Sometimes when setting a breakpoint a process doesn't stop on it.
      This is because the debug registers are not loaded correctly on
      VCPU load.
      
      The following simple reproducer from Oleg Nesterov tries using debug
      registers in two threads.  To see the bug, run a 2-VCPU guest with
      "taskset -c 0" and run "./bp 0 1" inside the guest.
      
          #include <unistd.h>
          #include <signal.h>
          #include <stdlib.h>
          #include <stdio.h>
          #include <sys/wait.h>
          #include <sys/ptrace.h>
          #include <sys/user.h>
          #include <asm/debugreg.h>
          #include <assert.h>
      
          #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
      
          unsigned long encode_dr7(int drnum, int enable, unsigned int type, unsigned int len)
          {
              unsigned long dr7;
      
              dr7 = ((len | type) & 0xf)
                  << (DR_CONTROL_SHIFT + drnum * DR_CONTROL_SIZE);
              if (enable)
                  dr7 |= (DR_GLOBAL_ENABLE << (drnum * DR_ENABLE_SIZE));
      
              return dr7;
          }
      
          int write_dr(int pid, int dr, unsigned long val)
          {
              return ptrace(PTRACE_POKEUSER, pid,
                      offsetof (struct user, u_debugreg[dr]),
                      val);
          }
      
          void set_bp(pid_t pid, void *addr)
          {
              unsigned long dr7;
              assert(write_dr(pid, 0, (long)addr) == 0);
              dr7 = encode_dr7(0, 1, DR_RW_EXECUTE, DR_LEN_1);
              assert(write_dr(pid, 7, dr7) == 0);
          }
      
          void *get_rip(int pid)
          {
              return (void*)ptrace(PTRACE_PEEKUSER, pid,
                      offsetof(struct user, regs.rip), 0);
          }
      
          void test(int nr)
          {
              void *bp_addr = &&label + nr, *bp_hit;
              int pid;
      
              printf("test bp %d\n", nr);
              assert(nr < 16); // see 16 asm nops below
      
              pid = fork();
              if (!pid) {
                  assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
                  kill(getpid(), SIGSTOP);
                  for (;;) {
                      label: asm (
                          "nop; nop; nop; nop;"
                          "nop; nop; nop; nop;"
                          "nop; nop; nop; nop;"
                          "nop; nop; nop; nop;"
                      );
                  }
              }
      
              assert(pid == wait(NULL));
              set_bp(pid, bp_addr);
      
              for (;;) {
                  assert(ptrace(PTRACE_CONT, pid, 0, 0) == 0);
                  assert(pid == wait(NULL));
      
                  bp_hit = get_rip(pid);
                  if (bp_hit != bp_addr)
                      fprintf(stderr, "ERR!! hit wrong bp %ld != %d\n",
                          bp_hit - &&label, nr);
              }
          }
      
          int main(int argc, const char *argv[])
          {
              while (--argc) {
                  int nr = atoi(*++argv);
                  if (!fork())
                      test(nr);
              }
      
              while (wait(NULL) > 0)
                  ;
              return 0;
          }
      Suggested-by: default avatarNadav Amit <namit@cs.technion.ac.il>
      Reported-by: default avatarAndrey Wagin <avagin@gmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fc90441e
    • Mark Rutland's avatar
      KVM: arm/arm64: vgic: Ensure bitmaps are long enough · d62cca11
      Mark Rutland authored
      commit 236cf17c upstream.
      
      When we allocate bitmaps in vgic_vcpu_init_maps, we divide the number of
      bits we need by 8 to figure out how many bytes to allocate. However,
      bitmap elements are always accessed as unsigned longs, and if we didn't
      happen to allocate a size such that size % sizeof(unsigned long) == 0,
      bitmap accesses may go past the end of the allocation.
      
      When using KASAN (which does byte-granular access checks), this results
      in a continuous stream of BUGs whenever these bitmaps are accessed:
      
      =============================================================================
      BUG kmalloc-128 (Tainted: G    B          ): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      INFO: Allocated in vgic_init.part.25+0x55c/0x990 age=7493 cpu=3 pid=1730
      INFO: Slab 0xffffffbde6d5da40 objects=16 used=15 fp=0xffffffc935769700 flags=0x4000000000000080
      INFO: Object 0xffffffc935769500 @offset=1280 fp=0x          (null)
      
      Bytes b4 ffffffc9357694f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769510: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769540: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769550: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769560: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffffffc935769570: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Padding ffffffc9357695b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Padding ffffffc9357695c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Padding ffffffc9357695d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Padding ffffffc9357695e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Padding ffffffc9357695f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      CPU: 3 PID: 1740 Comm: kvm-vcpu-0 Tainted: G    B           4.4.0+ #17
      Hardware name: ARM Juno development board (r1) (DT)
      Call trace:
      [<ffffffc00008e770>] dump_backtrace+0x0/0x280
      [<ffffffc00008ea04>] show_stack+0x14/0x20
      [<ffffffc000726360>] dump_stack+0x100/0x188
      [<ffffffc00030d324>] print_trailer+0xfc/0x168
      [<ffffffc000312294>] object_err+0x3c/0x50
      [<ffffffc0003140fc>] kasan_report_error+0x244/0x558
      [<ffffffc000314548>] __asan_report_load8_noabort+0x48/0x50
      [<ffffffc000745688>] __bitmap_or+0xc0/0xc8
      [<ffffffc0000d9e44>] kvm_vgic_flush_hwstate+0x1bc/0x650
      [<ffffffc0000c514c>] kvm_arch_vcpu_ioctl_run+0x2ec/0xa60
      [<ffffffc0000b9a6c>] kvm_vcpu_ioctl+0x474/0xa68
      [<ffffffc00036b7b0>] do_vfs_ioctl+0x5b8/0xcb0
      [<ffffffc00036bf34>] SyS_ioctl+0x8c/0xa0
      [<ffffffc000086cb0>] el0_svc_naked+0x24/0x28
      Memory state around the buggy address:
       ffffffc935769400: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffffffc935769480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffffffc935769500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                         ^
       ffffffc935769580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffffffc935769600: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
      ==================================================================
      
      Fix the issue by always allocating a multiple of sizeof(unsigned long),
      as we do elsewhere in the vgic code.
      
      Fixes: c1bfb577 ("arm/arm64: KVM: vgic: switch to dynamic allocation")
      Acked-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d62cca11
    • Christian Borntraeger's avatar
      KVM: async_pf: do not warn on page allocation failures · 85212a36
      Christian Borntraeger authored
      commit d7444794 upstream.
      
      In async_pf we try to allocate with NOWAIT to get an element quickly
      or fail. This code also handle failures gracefully. Lets silence
      potential page allocation failures under load.
      
      qemu-system-s39: page allocation failure: order:0,mode:0x2200000
      [...]
      Call Trace:
      ([<00000000001146b8>] show_trace+0xf8/0x148)
      [<000000000011476a>] show_stack+0x62/0xe8
      [<00000000004a36b8>] dump_stack+0x70/0x98
      [<0000000000272c3a>] warn_alloc_failed+0xd2/0x148
      [<000000000027709e>] __alloc_pages_nodemask+0x94e/0xb38
      [<00000000002cd36a>] new_slab+0x382/0x400
      [<00000000002cf7ac>] ___slab_alloc.constprop.30+0x2dc/0x378
      [<00000000002d03d0>] kmem_cache_alloc+0x160/0x1d0
      [<0000000000133db4>] kvm_setup_async_pf+0x6c/0x198
      [<000000000013dee8>] kvm_arch_vcpu_ioctl_run+0xd48/0xd58
      [<000000000012fcaa>] kvm_vcpu_ioctl+0x372/0x690
      [<00000000002f66f6>] do_vfs_ioctl+0x3be/0x510
      [<00000000002f68ec>] SyS_ioctl+0xa4/0xb8
      [<0000000000781c5e>] system_call+0xd6/0x264
      [<000003ffa24fa06a>] 0x3ffa24fa06a
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Reviewed-by: default avatarDominik Dingel <dingel@linux.vnet.ibm.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      85212a36
    • Robin Murphy's avatar
      of/irq: Fix msi-map calculation for nonzero rid-base · e1d61091
      Robin Murphy authored
      commit 5d589d81 upstream.
      
      The existing msi-map code is fine for shifting the entire RID space
      upwards, but attempting finer-grained remapping reveals a bug. It turns
      out that we are mistakenly treating the msi-base part as an offset, not
      as a new base to remap onto, so things get squiffy when rid-base is
      nonzero. Fix this, and at the same time add a sanity check against
      having msi-map-mask clash with a nonzero rid-base, as that's another
      thing one can easily get wrong.
      Signed-off-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Reviewed-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Tested-by: default avatarStuart Yoder <stuart.yoder@nxp.com>
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarDavid Daney <david.daney@cavium.com>
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e1d61091
    • Benjamin Coddington's avatar
      NFSv4: Fix a dentry leak on alias use · b8558ada
      Benjamin Coddington authored
      commit d9dfd8d7 upstream.
      
      In the case where d_add_unique() finds an appropriate alias to use it will
      have already incremented the reference count.  An additional dget() to swap
      the open context's dentry is unnecessary and will leak a reference.
      Signed-off-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Fixes: 275bb307 ("NFSv4: Move dentry instantiation into the NFSv4-...")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b8558ada
    • Christoph Hellwig's avatar
      nfs: fix nfs_size_to_loff_t · fd921e57
      Christoph Hellwig authored
      commit 50ab8ec7 upstream.
      
      See http: //www.infradead.org/rpr.html
      X-Evolution-Source: 1451162204.2173.11@leira.trondhjem.org
      Content-Transfer-Encoding: 8bit
      Mime-Version: 1.0
      
      We support OFFSET_MAX just fine, so don't round down below it.  Also
      switch to using min_t to make the helper more readable.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Fixes: 433c9237 ("NFS: Clean up nfs_size_to_loff_t()")
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd921e57
    • Mike Krinkin's avatar
      block: fix use-after-free in dio_bio_complete · 68a91855
      Mike Krinkin authored
      commit 7ddc971f upstream.
      
      kasan reported the following error when i ran xfstest:
      
      [  701.826854] ==================================================================
      [  701.826864] BUG: KASAN: use-after-free in dio_bio_complete+0x41a/0x600 at addr ffff880080b95f94
      [  701.826870] Read of size 4 by task loop2/3874
      [  701.826879] page:ffffea000202e540 count:0 mapcount:0 mapping:          (null) index:0x0
      [  701.826890] flags: 0x100000000000000()
      [  701.826895] page dumped because: kasan: bad access detected
      [  701.826904] CPU: 3 PID: 3874 Comm: loop2 Tainted: G    B   W    L  4.5.0-rc1-next-20160129 #83
      [  701.826910] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
      [  701.826917]  ffff88008fadf800 ffff88008fadf758 ffffffff81ca67bb 0000000041b58ab3
      [  701.826941]  ffffffff830d1e74 ffffffff81ca6724 ffff88008fadf748 ffffffff8161c05c
      [  701.826963]  0000000000000282 ffff88008fadf800 ffffed0010172bf2 ffffea000202e540
      [  701.826987] Call Trace:
      [  701.826997]  [<ffffffff81ca67bb>] dump_stack+0x97/0xdc
      [  701.827005]  [<ffffffff81ca6724>] ? _atomic_dec_and_lock+0xc4/0xc4
      [  701.827014]  [<ffffffff8161c05c>] ? __dump_page+0x32c/0x490
      [  701.827023]  [<ffffffff816b0d03>] kasan_report_error+0x5f3/0x8b0
      [  701.827033]  [<ffffffff817c302a>] ? dio_bio_complete+0x41a/0x600
      [  701.827040]  [<ffffffff816b1119>] __asan_report_load4_noabort+0x59/0x80
      [  701.827048]  [<ffffffff817c302a>] ? dio_bio_complete+0x41a/0x600
      [  701.827053]  [<ffffffff817c302a>] dio_bio_complete+0x41a/0x600
      [  701.827057]  [<ffffffff81bd19c8>] ? blk_queue_exit+0x108/0x270
      [  701.827060]  [<ffffffff817c32b0>] dio_bio_end_aio+0xa0/0x4d0
      [  701.827063]  [<ffffffff817c3210>] ? dio_bio_complete+0x600/0x600
      [  701.827067]  [<ffffffff81bd2806>] ? blk_account_io_completion+0x316/0x5d0
      [  701.827070]  [<ffffffff81bafe89>] bio_endio+0x79/0x200
      [  701.827074]  [<ffffffff81bd2c9f>] blk_update_request+0x1df/0xc50
      [  701.827078]  [<ffffffff81c02c27>] blk_mq_end_request+0x57/0x120
      [  701.827081]  [<ffffffff81c03670>] __blk_mq_complete_request+0x310/0x590
      [  701.827084]  [<ffffffff812348d8>] ? set_next_entity+0x2f8/0x2ed0
      [  701.827088]  [<ffffffff8124b34d>] ? put_prev_entity+0x22d/0x2a70
      [  701.827091]  [<ffffffff81c0394b>] blk_mq_complete_request+0x5b/0x80
      [  701.827094]  [<ffffffff821e2a33>] loop_queue_work+0x273/0x19d0
      [  701.827098]  [<ffffffff811f6578>] ? finish_task_switch+0x1c8/0x8e0
      [  701.827101]  [<ffffffff8129d058>] ? trace_hardirqs_on_caller+0x18/0x6c0
      [  701.827104]  [<ffffffff821e27c0>] ? lo_read_simple+0x890/0x890
      [  701.827108]  [<ffffffff8129dd60>] ? debug_check_no_locks_freed+0x350/0x350
      [  701.827111]  [<ffffffff811f63b0>] ? __hrtick_start+0x130/0x130
      [  701.827115]  [<ffffffff82a0c8f6>] ? __schedule+0x936/0x20b0
      [  701.827118]  [<ffffffff811dd6bd>] ? kthread_worker_fn+0x3ed/0x8d0
      [  701.827121]  [<ffffffff811dd4ed>] ? kthread_worker_fn+0x21d/0x8d0
      [  701.827125]  [<ffffffff8129d058>] ? trace_hardirqs_on_caller+0x18/0x6c0
      [  701.827128]  [<ffffffff811dd57f>] kthread_worker_fn+0x2af/0x8d0
      [  701.827132]  [<ffffffff811dd2d0>] ? __init_kthread_worker+0x170/0x170
      [  701.827135]  [<ffffffff82a1ea46>] ? _raw_spin_unlock_irqrestore+0x36/0x60
      [  701.827138]  [<ffffffff811dd2d0>] ? __init_kthread_worker+0x170/0x170
      [  701.827141]  [<ffffffff811dd2d0>] ? __init_kthread_worker+0x170/0x170
      [  701.827144]  [<ffffffff811dd00b>] kthread+0x24b/0x3a0
      [  701.827148]  [<ffffffff811dcdc0>] ? kthread_create_on_node+0x4c0/0x4c0
      [  701.827151]  [<ffffffff8129d70d>] ? trace_hardirqs_on+0xd/0x10
      [  701.827155]  [<ffffffff8116d41d>] ? do_group_exit+0xdd/0x350
      [  701.827158]  [<ffffffff811dcdc0>] ? kthread_create_on_node+0x4c0/0x4c0
      [  701.827161]  [<ffffffff82a1f52f>] ret_from_fork+0x3f/0x70
      [  701.827165]  [<ffffffff811dcdc0>] ? kthread_create_on_node+0x4c0/0x4c0
      [  701.827167] Memory state around the buggy address:
      [  701.827170]  ffff880080b95e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [  701.827172]  ffff880080b95f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [  701.827175] >ffff880080b95f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [  701.827177]                          ^
      [  701.827179]  ffff880080b96000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [  701.827182]  ffff880080b96080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
      [  701.827183] ==================================================================
      
      The problem is that bio_check_pages_dirty calls bio_put, so we must
      not access bio fields after bio_check_pages_dirty.
      
      Fixes: 9b81c842 ("block: don't access bio->bi_error after bio_put()").
      Signed-off-by: default avatarMike Krinkin <krinkin.m.u@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      68a91855
    • Hannes Reinecke's avatar
      bio: return EINTR if copying to user space got interrupted · 3e643b5c
      Hannes Reinecke authored
      commit 2d99b55d upstream.
      
      Commit 35dc2483 introduced a check for
      current->mm to see if we have a user space context and only copies data
      if we do. Now if an IO gets interrupted by a signal data isn't copied
      into user space any more (as we don't have a user space context) but
      user space isn't notified about it.
      
      This patch modifies the behaviour to return -EINTR from bio_uncopy_user()
      to notify userland that a signal has interrupted the syscall, otherwise
      it could lead to a situation where the caller may get a buffer with
      no data returned.
      
      This can be reproduced by issuing SG_IO ioctl()s in one thread while
      constantly sending signals to it.
      
      Fixes: 35dc2483 [SCSI] sg: Fix user memory corruption when SG_IO is interrupted by a signal
      Signed-off-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e643b5c
    • Alexandra Yates's avatar
      i2c: i801: Adding Intel Lewisburg support for iTCO · 023e29e4
      Alexandra Yates authored
      commit 1a1503c5 upstream.
      
      Starting from Intel Sunrisepoint (Skylake PCH) the iTCO watchdog
      resources have been moved to reside under the i801 SMBus host
      controller whereas previously they were under the LPC device.
      
      This patch adds Intel lewisburg SMBus support for iTCO device.
      It allows to load watchdog dynamically when the hardware is
      present.
      
      Fixes: cdc5a311 ("i2c: i801: add Intel Lewisburg device IDs")
      Reviewed-by: default avatarJean Delvare <jdelvare@suse.de>
      Signed-off-by: default avatarAlexandra Yates <alexandra.yates@linux.intel.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      023e29e4
    • Shawn Lin's avatar
      phy: core: fix wrong err handle for phy_power_on · be683dfd
      Shawn Lin authored
      commit b82fcabe upstream.
      
      If phy_pm_runtime_get_sync failed but we already
      enable regulator, current code return directly without
      doing regulator_disable. This patch fix this problem
      and cleanup err handle of phy_power_on to be more readable.
      
      Fixes: 3be88125 ("phy: core: Support regulator ...")
      Cc: Roger Quadros <rogerq@ti.com>
      Cc: Axel Lin <axel.lin@ingics.com>
      Signed-off-by: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be683dfd
    • Tejun Heo's avatar
      writeback: keep superblock pinned during cgroup writeback association switches · 7c465723
      Tejun Heo authored
      commit 5ff8eaac upstream.
      
      If cgroup writeback is in use, an inode is associated with a cgroup
      for writeback.  If the inode's main dirtier changes to another cgroup,
      the association gets updated asynchronously.  Nothing was pinning the
      superblock while such switches are in progress and superblock could go
      away while async switching is pending or in progress leading to
      crashes like the following.
      
       kernel BUG at fs/jbd2/transaction.c:319!
       invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
       CPU: 1 PID: 29158 Comm: kworker/1:10 Not tainted 4.5.0-rc3 #51
       Hardware name: Google Google, BIOS Google 01/01/2011
       Workqueue: events inode_switch_wbs_work_fn
       task: ffff880213dbbd40 ti: ffff880209264000 task.ti: ffff880209264000
       RIP: 0010:[<ffffffff803e6922>]  [<ffffffff803e6922>] start_this_handle+0x382/0x3e0
       RSP: 0018:ffff880209267c30  EFLAGS: 00010202
       ...
       Call Trace:
        [<ffffffff803e6be4>] jbd2__journal_start+0xf4/0x190
        [<ffffffff803cfc7e>] __ext4_journal_start_sb+0x4e/0x70
        [<ffffffff803b31ec>] ext4_evict_inode+0x12c/0x3d0
        [<ffffffff8035338b>] evict+0xbb/0x190
        [<ffffffff80354190>] iput+0x130/0x190
        [<ffffffff80360223>] inode_switch_wbs_work_fn+0x343/0x4c0
        [<ffffffff80279819>] process_one_work+0x129/0x300
        [<ffffffff80279b16>] worker_thread+0x126/0x480
        [<ffffffff8027ed14>] kthread+0xc4/0xe0
        [<ffffffff809771df>] ret_from_fork+0x3f/0x70
      
      Fix it by bumping s_active while cgroup association switching is in
      flight.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-and-tested-by: default avatarTahsin Erdogan <tahsin@google.com>
      Link: http://lkml.kernel.org/g/CAAeU0aNCq7LGODvVGRU-oU_o-6enii5ey0p1c26D1ZzYwkDc5A@mail.gmail.com
      Fixes: d10c8095 ("writeback: implement foreign cgroup inode bdi_writeback switching")
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c465723