1. 14 8月, 2017 34 次提交
  2. 13 8月, 2017 1 次提交
  3. 11 8月, 2017 5 次提交
    • A
      iommu/arm-smmu: fix null-pointer dereference in arm_smmu_add_device · a7990c64
      Artem Savkov 提交于
      Commit c54451a5 "iommu/arm-smmu: Fix the error path in arm_smmu_add_device"
      removed fwspec assignment in legacy_binding path as redundant which is
      wrong. It needs to be updated after fwspec initialisation in
      arm_smmu_register_legacy_master() as it is dereferenced later. Without
      this there is a NULL-pointer dereference panic during boot on some hosts.
      Signed-off-by: NArtem Savkov <asavkov@redhat.com>
      Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      a7990c64
    • L
      xen/events: Fix interrupt lost during irq_disable and irq_enable · 020db9d3
      Liu Shuo 提交于
      Here is a device has xen-pirq-MSI interrupt. Dom0 might lost interrupt
      during driver irq_disable/irq_enable. Here is the scenario,
       1. irq_disable -> disable_dynirq -> mask_evtchn(irq channel)
       2. dev interrupt raised by HW and Xen mark its evtchn as pending
       3. irq_enable -> startup_pirq -> eoi_pirq ->
          clear_evtchn(channel of irq) -> clear pending status
       4. consume_one_event process the irq event without pending bit assert
          which result in interrupt lost once
       5. No HW interrupt raising anymore.
      
      Now use enable_dynirq for enable_pirq of xen_pirq_chip to remove
      eoi_pirq when irq_enable.
      Signed-off-by: NLiu Shuo <shuo.a.liu@intel.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      020db9d3
    • J
      xen: avoid deadlock in xenbus · 529871bb
      Juergen Gross 提交于
      When starting the xenwatch thread a theoretical deadlock situation is
      possible:
      
      xs_init() contains:
      
          task = kthread_run(xenwatch_thread, NULL, "xenwatch");
          if (IS_ERR(task))
              return PTR_ERR(task);
          xenwatch_pid = task->pid;
      
      And xenwatch_thread() does:
      
          mutex_lock(&xenwatch_mutex);
          ...
          event->handle->callback();
          ...
          mutex_unlock(&xenwatch_mutex);
      
      The callback could call unregister_xenbus_watch() which does:
      
          ...
          if (current->pid != xenwatch_pid)
              mutex_lock(&xenwatch_mutex);
          ...
      
      In case a watch is firing before xenwatch_pid could be set and the
      callback of that watch unregisters a watch, then a self-deadlock would
      occur.
      
      Avoid this by setting xenwatch_pid in xenwatch_thread().
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: NJuergen Gross <jgross@suse.com>
      529871bb
    • M
      zram: rework copy of compressor name in comp_algorithm_store() · f357e345
      Matthias Kaehlcke 提交于
      comp_algorithm_store() passes the size of the source buffer to strlcpy()
      instead of the destination buffer size.  Make it explicit that the two
      buffers have the same size and use strcpy() instead of strlcpy().  The
      latter can be done safely since the function ensures that the string in
      the source buffer is terminated.
      
      Link: http://lkml.kernel.org/r/20170803163350.45245-1-mka@chromium.orgSigned-off-by: NMatthias Kaehlcke <mka@chromium.org>
      Reviewed-by: NDouglas Anderson <dianders@chromium.org>
      Reviewed-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Acked-by: NMinchan Kim <minchan@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f357e345
    • M
      thunderbolt: Do not enumerate more ports from DROM than the controller has · 1cd65d17
      Mika Westerberg 提交于
      Some Alpine Ridge LP DROMs (there might be others) erroneusly list more
      ports than the controller actually has. Most probably because DROM of
      the full Dual/Single port Thunderbolt controller was reused for LP
      version. The current DROM parser does not check the upper bound thus it
      leads to crash when sw->ports[] is accessed over bounds:
      
       BUG: unable to handle kernel NULL pointer dereference at 00000000000002ec
       IP: tb_drom_read+0x383/0x890 [thunderbolt]
       PGD 0
       P4D 0
       Oops: 0000 [#1] SMP
       CPU: 3 PID: 12248 Comm: systemd-udevd Not tainted 4.13.0-rc1-next-20170719 #1
       Hardware name: LENOVO 20HF000YGE/20HF000YGE, BIOS N1WET32W (1.11 ) 05/23/2017
       task: ffff8a293e4bcd80 task.stack: ffffa698027a8000
       RIP: 0010:tb_drom_read+0x383/0x890 [thunderbolt]
       RSP: 0018:ffffa698027ab990 EFLAGS: 00010246
       RAX: 0000000000000000 RBX: ffff8a2940af7800 RCX: 0000000000000000
       RDX: ffff8a2940ebb400 RSI: 0000000000000000 RDI: ffffa698027ab9a0
       RBP: ffffa698027ab9d0 R08: 0000000000000001 R09: 0000000000000002
       R10: ffff8a2940ebb5b0 R11: 0000000000000000 R12: ffff8a293bfa968c
       R13: 000000000000002c R14: 0000000000000056 R15: 0000000000000056
       FS:  00007f0a945a38c0(0000) GS:ffff8a2961580000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00000000000002ec CR3: 000000043e785000 CR4: 00000000003606e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        tb_switch_add+0x9d/0x730 [thunderbolt]
        ? tb_switch_alloc+0x3cd/0x4d0 [thunderbolt]
        icm_start+0x5a/0xa0 [thunderbolt]
        tb_domain_add+0xc3/0xf0 [thunderbolt]
        nhi_probe+0x19e/0x310 [thunderbolt]
        local_pci_probe+0x42/0xa0
        pci_device_probe+0x18d/0x1a0
        driver_probe_device+0x2ff/0x450
        __driver_attach+0xa4/0xe0
        ? driver_probe_device+0x450/0x450
        bus_for_each_dev+0x6e/0xb0
        driver_attach+0x1e/0x20
        bus_add_driver+0x1d0/0x270
        ? 0xffffffffc0bbb000
        driver_register+0x60/0xe0
        ? 0xffffffffc0bbb000
        __pci_register_driver+0x4c/0x50
        nhi_init+0x28/0x1000 [thunderbolt]
        do_one_initcall+0x50/0x190
        ? __vunmap+0x81/0xb0
        ? _cond_resched+0x1a/0x50
        ? kmem_cache_alloc_trace+0x15f/0x1c0
        ? do_init_module+0x27/0x1e9
        do_init_module+0x5f/0x1e9
        load_module+0x24e7/0x2a60
        ? vfs_read+0x115/0x130
        SYSC_finit_module+0xfc/0x120
        ? SYSC_finit_module+0xfc/0x120
        SyS_finit_module+0xe/0x10
        do_syscall_64+0x67/0x170
        entry_SYSCALL64_slow_path+0x25/0x25
      
      Fix this by making sure we only enumerate DROM port entries the hardware
      actually has.
      Reported-by: NChristian Kellner <ckellner@redhat.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: NLukas Wunner <lukas@wunner.de>
      Tested-by: NChristian Kellner <ckellner@redhat.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1cd65d17