Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 14 12月, 2015 2 次提交
  3. 15 10月, 2015 1 次提交
    • J
      iommu/amd: Fix BUG when faulting a PROT_NONE VMA · d14f6fce
      由 Jay Cornwall 提交于 
      handle_mm_fault indirectly triggers a BUG in do_numa_page
when given a VMA without read/write/execute access. Check
this condition in do_fault.

do_fault -> handle_mm_fault -> handle_pte_fault -> do_numa_page

  mm/memory.c
  3147  static int do_numa_page(struct mm_struct *mm, struct vm_area_struct *vma,
  ....
  3159  /* A PROT_NONE fault should not end up here */
  3160  BUG_ON(!(vma->vm_flags & (VM_READ | VM_EXEC | VM_WRITE)));
Signed-off-by: NJay Cornwall <jay@jcornwall.me>
Cc: <stable@vger.kernel.org> # v4.1+
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      d14f6fce
  5. 14 8月, 2015 1 次提交
  7. 30 7月, 2015 1 次提交
  9. 04 5月, 2015 1 次提交
  11. 04 3月, 2015 1 次提交
  13. 04 2月, 2015 3 次提交
  15. 14 12月, 2014 1 次提交
  17. 12 11月, 2014 1 次提交
    • O
      iommu/amd: Fix accounting of device_state · 1c51099a
      由 Oded Gabbay 提交于 
      This patch fixes a bug in the accounting of the
device_state.  In the current code, the device_state was put
(decremented) too many times, which sometimes lead to the
driver getting stuck permanently in put_device_state_wait().
That happen because the device_state->count would go below
zero, which is never supposed to happen.

The root cause is that the device_state was decremented in
put_pasid_state() and put_pasid_state_wait() but also in all
the functions that call those functions. Therefore, the
device_state was decremented twice in each of these code
paths.

The fix is to decouple the device_state accounting from the
pasid_state accounting - remove the call to
put_device_state() from the put_pasid_state() and the
put_pasid_state_wait())
Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      1c51099a
  19. 24 9月, 2014 1 次提交
    • A
      kvm: Fix page ageing bugs · 57128468
      由 Andres Lagar-Cavilla 提交于 
      1. We were calling clear_flush_young_notify in unmap_one, but we are
within an mmu notifier invalidate range scope. The spte exists no more
(due to range_start) and the accessed bit info has already been
propagated (due to kvm_pfn_set_accessed). Simply call
clear_flush_young.

2. We clear_flush_young on a primary MMU PMD, but this may be mapped
as a collection of PTEs by the secondary MMU (e.g. during log-dirty).
This required expanding the interface of the clear_flush_young mmu
notifier, so a lot of code has been trivially touched.

3. In the absence of shadow_accessed_mask (e.g. EPT A bit), we emulate
the access bit by blowing the spte. This requires proper synchronizing
with MMU notifier consumers, like every other removal of spte's does.
Signed-off-by: NAndres Lagar-Cavilla <andreslc@google.com>
Acked-by: NRik van Riel <riel@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      57128468
  21. 30 7月, 2014 4 次提交
  23. 10 7月, 2014 9 次提交
  25. 09 7月, 2014 1 次提交
  27. 20 6月, 2014 1 次提交
    • J
      iommu/amd: Fix small race between invalidate_range_end/start · d73a6d72
      由 Joerg Roedel 提交于 
      Commit e79df31c introduced mmu_notifer_count to protect
against parallel mmu_notifier_invalidate_range_start/end
calls. The patch left a small race condition when
invalidate_range_end() races with a new
invalidate_range_start() the empty page-table may be
reverted leading to stale TLB entries in the IOMMU and the
device. Use a spin_lock instead of just an atomic variable
to eliminate the race.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      d73a6d72
  29. 26 5月, 2014 5 次提交
  31. 13 5月, 2014 1 次提交
  33. 10 11月, 2014 1 次提交
    • O
      iommu/amd: fix accounting of device_state · a015c1e9
      由 Oded Gabbay 提交于 
      This patch fixes a bug in the accounting of the device_state.
In the current code, the device_state was put (decremented) too many times,
which sometimes lead to the driver getting stuck permanently in
put_device_state_wait(). That happen because the device_state->count would go
below zero, which is never supposed to happen.

The root cause is that the device_state was decremented in put_pasid_state()
and put_pasid_state_wait() but also in all the functions that call those
functions. Therefore, the device_state was decremented twice in each of these
code paths.

The fix is to decouple the device_state accounting from the pasid_state
accounting - remove the call to put_device_state() from the
put_pasid_state() and the put_pasid_state_wait())
Signed-off-by: NOded Gabbay <oded.gabbay@amd.com>
      a015c1e9
  35. 13 11月, 2014 1 次提交
  37. 24 7月, 2012 1 次提交
  39. 19 7月, 2012 1 次提交
  41. 17 7月, 2012 1 次提交
  43. 15 3月, 2012 1 次提交