1. 18 12月, 2013 1 次提交
  2. 03 12月, 2013 1 次提交
  3. 16 11月, 2013 1 次提交
  4. 02 11月, 2013 1 次提交
    • M
      drm/radeon: fixup locking inversion between, mmap_sem and reservations · 28a326c5
      Maarten Lankhorst 提交于
      op 08-10-13 18:58, Thomas Hellstrom schreef:
      > On 10/08/2013 06:47 PM, Jerome Glisse wrote:
      >> On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote:
      >>> On 10/08/2013 04:55 PM, Jerome Glisse wrote:
      >>>> On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
      >>>>> Am 08.10.2013 16:33, schrieb Jerome Glisse:
      >>>>>> On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
      >>>>>>> Allocate and copy all kernel memory before doing reservations. This prevents a locking
      >>>>>>> inversion between mmap_sem and reservation_class, and allows us to drop the trylocking
      >>>>>>> in ttm_bo_vm_fault without upsetting lockdep.
      >>>>>>>
      >>>>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      >>>>>> I would say NAK. Current code only allocate temporary page in AGP case.
      >>>>>> So AGP case is userspace -> temp page -> cs checker -> radeon ib.
      >>>>>>
      >>>>>> Non AGP is directly memcpy to radeon IB.
      >>>>>>
      >>>>>> Your patch allocate memory memcpy userspace to it and it will then be
      >>>>>> memcpy to IB. Which means you introduce an extra memcpy in the process
      >>>>>> not something we want.
      >>>>> Totally agree. Additional to that there is no good reason to provide
      >>>>> anything else than anonymous system memory to the CS ioctl, so the
      >>>>> dependency between the mmap_sem and reservations are not really
      >>>>> clear to me.
      >>>>>
      >>>>> Christian.
      >>>> I think is that in other code path you take mmap_sem first then reserve
      >>>> bo. But here we reserve bo and then we take mmap_sem because of copy
      >>> >from user.
      >>>> Cheers,
      >>>> Jerome
      >>>>
      >>> Actually the log message is a little confusing. I think the mmap_sem
      >>> locking inversion problem is orthogonal to what's being fixed here.
      
      > >>> This patch fixes the possible recursive bo::reserve caused by
      > >>> malicious user-space handing a pointer to ttm memory so that the ttm
      > >>> fault handler is called when bos are already reserved. That may
      > >>> cause a (possibly interruptible) livelock.
      
      >>> Once that is fixed, we are free to choose the mmap_sem ->
      >>> bo::reserve locking order. Currently it's bo::reserve->mmap_sem(),
      >>> but the hack required in the ttm fault handler is admittedly a bit
      >>> ugly.  The plan is to change the locking order to
      >>> mmap_sem->bo::reserve
      
      > >>> I'm not sure if it applies to this particular case, but it should be
      > >>> possible to make sure that copy_from_user_inatomic() will always
      > >>> succeed, by making sure the pages are present using
      > >>> get_user_pages(), and release the pages after
      > >>> copy_from_user_inatomic() is done. That way there's no need for a
      > >>> double memcpy slowpath, but if the copied data is very fragmented I
      > >>> guess the resulting code may look ugly. The get_user_pages()
      > >>> function will return an error if it hits TTM pages.
      
      >>> /Thomas
      >> get_user_pages + copy_from_user_inatomic is overkill. We should just
      >> do get_user_pages which fails with ttm memory and then use copy_highpage
      >> helper.
      >>
      >> Cheers,
      >> Jerome
      > Yeah, it may well be that that's the preferred solution.
      >
      > /Thomas
      >
      I still disagree, and shuffled radeon_ib_get around to be called sooner.
      
      How does the patch below look?
      8<-------
      Allocate and copy all kernel memory before doing reservations. This prevents a locking
      inversion between mmap_sem and reservation_class, and allows us to drop the trylocking
      in ttm_bo_vm_fault without upsetting lockdep.
      
      Changes since v1:
      - Kill extra memcpy for !AGP case.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Reviewed-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      28a326c5
  5. 19 10月, 2013 1 次提交
  6. 23 9月, 2013 1 次提交
  7. 21 9月, 2013 1 次提交
  8. 16 9月, 2013 1 次提交
  9. 11 9月, 2013 1 次提交
  10. 31 8月, 2013 2 次提交
  11. 28 6月, 2013 2 次提交
  12. 27 6月, 2013 1 次提交
    • A
      drm/radeon/cik: Add support for compute queues (v4) · 963e81f9
      Alex Deucher 提交于
      On CIK, the compute rings work slightly differently than
      on previous asics, however the basic concepts are the same.
      
      The main differences:
      - New MEC engines for compute queues
      - Multiple queues per MEC:
        - CI/KB: 1 MEC, 4 pipes per MEC, 8 queues per pipe = 32 queues
        -    KV: 2 MEC, 4 pipes per MEC, 8 queues per pipe = 64 queues
      - Queues can be allocated and scheduled by another queue
      - New doorbell aperture allows you to assign space in the aperture
        for the wptr which allows for userspace access to queues
      
      v2: add wptr shadow, fix eop setup
      v3: fix comment
      v4: switch to new callback method
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: NJerome Glisse <jglisse@redhat.com>
      963e81f9
  13. 26 6月, 2013 1 次提交
    • A
      drm/radeon: Add CP init for CIK (v7) · 841cf442
      Alex Deucher 提交于
      Sets up the GFX ring and loads ucode for GFX and Compute.
      
      Todo:
      - handle compute queue setup.
      
      v2: add documentation
      v3: integrate with latest reset changes
      v4: additional init fixes
      v5: scratch reg write back no longer supported on CIK
      v6: properly set CP_RB0_BASE_HI
      v7: rebase
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      841cf442
  14. 24 4月, 2013 1 次提交
  15. 09 4月, 2013 3 次提交
  16. 02 2月, 2013 1 次提交
  17. 01 2月, 2013 6 次提交
  18. 24 1月, 2013 1 次提交
    • I
      drm/radeon: fix a rare case of double kfree · 1da80cfa
      Ilija Hadzic 提交于
      If one (but not both) allocations of p->chunks[].kpage[]
      in radeon_cs_parser_init fail, the error path will free
      the successfully allocated page, but leave a stale pointer
      value in the kpage[] field. This will later cause a
      double-free when radeon_cs_parser_fini is called.
      This patch fixes the issue by forcing both pointers to NULL
      after kfree in the error path.
      
      The circumstances under which the problem happens are very
      rare. The card must be AGP and the system must run out of
      kmalloc area just at the right time so that one allocation
      succeeds, while the other fails.
      Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com>
      Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      1da80cfa
  19. 11 1月, 2013 2 次提交
  20. 14 12月, 2012 2 次提交
  21. 16 10月, 2012 1 次提交
  22. 03 10月, 2012 1 次提交
  23. 21 9月, 2012 7 次提交