1. 28 Jun, 2019 5 commits
  2. 26 Jun, 2019 5 commits
  3. 25 Jun, 2019 17 commits
  4. 24 Jun, 2019 6 commits
  5. 22 Jun, 2019 7 commits
    • Linus Torvalds's avatar
      Linux 5.2-rc6 · 4b972a01
      Linus Torvalds authored
      4b972a01
    • Linus Torvalds's avatar
      Merge tag 'iommu-fix-v5.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu · 6698a71a
      Linus Torvalds authored
      Pull iommu fix from Joerg Roedel:
       "Revert a commit from the previous pile of fixes which causes new
        lockdep splats. It is better to revert it for now and work on a better
        and more well tested fix"
      
      * tag 'iommu-fix-v5.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
        Revert "iommu/vt-d: Fix lock inversion between iommu->lock and device_domain_lock"
      6698a71a
    • Peter Xu's avatar
      Revert "iommu/vt-d: Fix lock inversion between iommu->lock and device_domain_lock" · 0aafc8ae
      Peter Xu authored
      This reverts commit 7560cc3c.
      
      With 5.2.0-rc5 I can easily trigger this with lockdep and iommu=pt:
      
          ======================================================
          WARNING: possible circular locking dependency detected
          5.2.0-rc5 #78 Not tainted
          ------------------------------------------------------
          swapper/0/1 is trying to acquire lock:
          00000000ea2b3beb (&(&iommu->lock)->rlock){+.+.}, at: domain_context_mapping_one+0xa5/0x4e0
          but task is already holding lock:
          00000000a681907b (device_domain_lock){....}, at: domain_context_mapping_one+0x8d/0x4e0
          which lock already depends on the new lock.
          the existing dependency chain (in reverse order) is:
          -> #1 (device_domain_lock){....}:
                 _raw_spin_lock_irqsave+0x3c/0x50
                 dmar_insert_one_dev_info+0xbb/0x510
                 domain_add_dev_info+0x50/0x90
                 dev_prepare_static_identity_mapping+0x30/0x68
                 intel_iommu_init+0xddd/0x1422
                 pci_iommu_init+0x16/0x3f
                 do_one_initcall+0x5d/0x2b4
                 kernel_init_freeable+0x218/0x2c1
                 kernel_init+0xa/0x100
                 ret_from_fork+0x3a/0x50
          -> #0 (&(&iommu->lock)->rlock){+.+.}:
                 lock_acquire+0x9e/0x170
                 _raw_spin_lock+0x25/0x30
                 domain_context_mapping_one+0xa5/0x4e0
                 pci_for_each_dma_alias+0x30/0x140
                 dmar_insert_one_dev_info+0x3b2/0x510
                 domain_add_dev_info+0x50/0x90
                 dev_prepare_static_identity_mapping+0x30/0x68
                 intel_iommu_init+0xddd/0x1422
                 pci_iommu_init+0x16/0x3f
                 do_one_initcall+0x5d/0x2b4
                 kernel_init_freeable+0x218/0x2c1
                 kernel_init+0xa/0x100
                 ret_from_fork+0x3a/0x50
      
          other info that might help us debug this:
           Possible unsafe locking scenario:
                 CPU0                    CPU1
                 ----                    ----
            lock(device_domain_lock);
                                         lock(&(&iommu->lock)->rlock);
                                         lock(device_domain_lock);
            lock(&(&iommu->lock)->rlock);
      
           *** DEADLOCK ***
          2 locks held by swapper/0/1:
           #0: 00000000033eb13d (dmar_global_lock){++++}, at: intel_iommu_init+0x1e0/0x1422
           #1: 00000000a681907b (device_domain_lock){....}, at: domain_context_mapping_one+0x8d/0x4e0
      
          stack backtrace:
          CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc5 #78
          Hardware name: LENOVO 20KGS35G01/20KGS35G01, BIOS N23ET50W (1.25 ) 06/25/2018
          Call Trace:
           dump_stack+0x85/0xc0
           print_circular_bug.cold.57+0x15c/0x195
           __lock_acquire+0x152a/0x1710
           lock_acquire+0x9e/0x170
           ? domain_context_mapping_one+0xa5/0x4e0
           _raw_spin_lock+0x25/0x30
           ? domain_context_mapping_one+0xa5/0x4e0
           domain_context_mapping_one+0xa5/0x4e0
           ? domain_context_mapping_one+0x4e0/0x4e0
           pci_for_each_dma_alias+0x30/0x140
           dmar_insert_one_dev_info+0x3b2/0x510
           domain_add_dev_info+0x50/0x90
           dev_prepare_static_identity_mapping+0x30/0x68
           intel_iommu_init+0xddd/0x1422
           ? printk+0x58/0x6f
           ? lockdep_hardirqs_on+0xf0/0x180
           ? do_early_param+0x8e/0x8e
           ? e820__memblock_setup+0x63/0x63
           pci_iommu_init+0x16/0x3f
           do_one_initcall+0x5d/0x2b4
           ? do_early_param+0x8e/0x8e
           ? rcu_read_lock_sched_held+0x55/0x60
           ? do_early_param+0x8e/0x8e
           kernel_init_freeable+0x218/0x2c1
           ? rest_init+0x230/0x230
           kernel_init+0xa/0x100
           ret_from_fork+0x3a/0x50
      
      domain_context_mapping_one() is taking device_domain_lock first then
      iommu lock, while dmar_insert_one_dev_info() is doing the reverse.
      
      That should be introduced by commit:
      
      7560cc3c ("iommu/vt-d: Fix lock inversion between iommu->lock and
                    device_domain_lock", 2019-05-27)
      
      So far I still cannot figure out how the previous deadlock was
      triggered (I cannot find iommu lock taken before calling of
      iommu_flush_dev_iotlb()), however I'm pretty sure that that change
      should be incomplete at least because it does not fix all the places
      so we're still taking the locks in different orders, while reverting
      that commit is very clean to me so far that we should always take
      device_domain_lock first then the iommu lock.
      
      We can continue to try to find the real culprit mentioned in
      7560cc3c, but for now I think we should revert it to fix current
      breakage.
      
      CC: Joerg Roedel <joro@8bytes.org>
      CC: Lu Baolu <baolu.lu@linux.intel.com>
      CC: dave.jiang@intel.com
      Signed-off-by: default avatarPeter Xu <peterx@redhat.com>
      Tested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      0aafc8ae
    • Linus Torvalds's avatar
      Merge tag 'pci-v5.2-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci · b253d5f3
      Linus Torvalds authored
      Pull PCI fix from Bjorn Helgaas:
       "If an IOMMU is present, ignore the P2PDMA whitelist we added for v5.2
        because we don't yet know how to support P2PDMA in that case (Logan
        Gunthorpe)"
      
      * tag 'pci-v5.2-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
        PCI/P2PDMA: Ignore root complex whitelist when an IOMMU is present
      b253d5f3
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · f4102766
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Three driver fixes (and one version number update): a suspend hang in
        ufs, a qla hard lock on module removal and a qedi panic during
        discovery"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: qla2xxx: Fix hardlockup in abort command during driver remove
        scsi: ufs: Avoid runtime suspend possibly being blocked forever
        scsi: qedi: update driver version to 8.37.0.20
        scsi: qedi: Check targetname while finding boot target information
      f4102766
    • Linus Torvalds's avatar
      Merge tag 'powerpc-5.2-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux · a8282bf0
      Linus Torvalds authored
      Pull powerpc fixes from Michael Ellerman:
       "This is a frustratingly large batch at rc5. Some of these were sent
        earlier but were missed by me due to being distracted by other things,
        and some took a while to track down due to needing manual bisection on
        old hardware. But still we clearly need to improve our testing of KVM,
        and of 32-bit, so that we catch these earlier.
      
        Summary: seven fixes, all for bugs introduced this cycle.
      
         - The commit to add KASAN support broke booting on 32-bit SMP
           machines, due to a refactoring that moved some setup out of the
           secondary CPU path.
      
         - A fix for another 32-bit SMP bug introduced by the fast syscall
           entry implementation for 32-bit BOOKE. And a build fix for the same
           commit.
      
         - Our change to allow the DAWR to be force enabled on Power9
           introduced a bug in KVM, where we clobber r3 leading to a host
           crash.
      
         - The same commit also exposed a previously unreachable bug in the
           nested KVM handling of DAWR, which could lead to an oops in a
           nested host.
      
         - One of the DMA reworks broke the b43legacy WiFi driver on some
           people's powermacs, fix it by enabling a 30-bit ZONE_DMA on 32-bit.
      
         - A fix for TLB flushing in KVM introduced a new bug, as it neglected
           to also flush the ERAT, this could lead to memory corruption in the
           guest.
      
        Thanks to: Aaro Koskinen, Christoph Hellwig, Christophe Leroy, Larry
        Finger, Michael Neuling, Suraj Jitindar Singh"
      
      * tag 'powerpc-5.2-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
        KVM: PPC: Book3S HV: Invalidate ERAT when flushing guest TLB entries
        powerpc: enable a 30-bit ZONE_DMA for 32-bit pmac
        KVM: PPC: Book3S HV: Only write DAWR[X] when handling h_set_dawr in real mode
        KVM: PPC: Book3S HV: Fix r3 corruption in h_set_dabr()
        powerpc/32: fix build failure on book3e with KVM
        powerpc/booke: fix fast syscall entry on SMP
        powerpc/32s: fix initial setup of segment registers on secondary CPU
      a8282bf0
    • Marcel Holtmann's avatar
      Bluetooth: Fix regression with minimum encryption key size alignment · 693cd8ce
      Marcel Holtmann authored
      When trying to align the minimum encryption key size requirement for
      Bluetooth connections, it turns out doing this in a central location in
      the HCI connection handling code is not possible.
      
      Original Bluetooth version up to 2.0 used a security model where the
      L2CAP service would enforce authentication and encryption.  Starting
      with Bluetooth 2.1 and Secure Simple Pairing that model has changed into
      that the connection initiator is responsible for providing an encrypted
      ACL link before any L2CAP communication can happen.
      
      Now connecting Bluetooth 2.1 or later devices with Bluetooth 2.0 and
      before devices are causing a regression.  The encryption key size check
      needs to be moved out of the HCI connection handling into the L2CAP
      channel setup.
      
      To achieve this, the current check inside hci_conn_security() has been
      moved into l2cap_check_enc_key_size() helper function and then called
      from four decisions point inside L2CAP to cover all combinations of
      Secure Simple Pairing enabled devices and device using legacy pairing
      and legacy service security model.
      
      Fixes: d5bb334a ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections")
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203643Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      693cd8ce