1. 11 8月, 2016 1 次提交
    • G
      dma-buf/sync_file: refactor fence storage in struct sync_file · a02b9dc9
      Gustavo Padovan 提交于
      Create sync_file->fence to abstract the type of fence we are using for
      each sync_file. If only one fence is present we use a normal struct fence
      but if there is more fences to be added to the sync_file a fence_array
      is created.
      
      This change cleans up sync_file a bit. We don't need to have sync_file_cb
      array anymore. Instead, as we always have  one fence, only one fence
      callback is registered per sync_file.
      
      v2: Comments from Chris Wilson and Christian König
      	- Not using fence_ops anymore
      	- fence_is_array() was created to differentiate fence from fence_array
      	- fence_array_teardown() is now exported and used under fence_is_array()
      	- struct sync_file lost num_fences member
      
      v3: Comments from Chris Wilson and Christian König
      	- struct sync_file lost status member in favor of fence_is_signaled()
      	- drop use of fence_array_teardown()
      	- use sizeof(*fence) to allocate only an array on fence pointers
      
      v4: Comments from Chris Wilson
      	- use sizeof(*fence) to reallocate array
      	- fix typo in comments
      	- protect num_fences sum against overflows
      	- use array->base instead of casting the to struct fence
      
      v5: fixes checkpatch warnings
      
      v6: fix case where all fences are signaled.
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: NChristian König <christian.koenig@amd.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
      a02b9dc9
  2. 04 6月, 2016 1 次提交
  3. 30 4月, 2016 11 次提交
  4. 21 2月, 2016 1 次提交
  5. 08 2月, 2016 13 次提交
  6. 22 12月, 2015 2 次提交
  7. 16 11月, 2015 2 次提交
  8. 26 3月, 2015 1 次提交
    • A
      staging: android: sync: Fix memory corruption in sync_timeline_signal(). · 8e43c9c7
      Alistair Strachan 提交于
      The android_fence_release() function checks for active sync points
      by calling list_empty() on the list head embedded on the sync
      point. However, it is only valid to use list_empty() on nodes that
      have been initialized with INIT_LIST_HEAD() or list_del_init().
      
      Because the list entry has likely been removed from the active list
      by sync_timeline_signal(), there is a good chance that this
      WARN_ON_ONCE() will be hit due to dangling pointers pointing at
      freed memory (even though the sync drivers did nothing wrong)
      and memory corruption will ensue as the list entry is removed for
      a second time, corrupting the active list.
      
      This problem can be reproduced quite easily with CONFIG_DEBUG_LIST=y
      and fences with more than one sync point.
      Signed-off-by: NAlistair Strachan <alistair.strachan@imgtec.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Colin Cross <ccross@google.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e43c9c7
  9. 09 9月, 2014 1 次提交
  10. 03 9月, 2014 1 次提交
  11. 31 8月, 2014 1 次提交
  12. 16 7月, 2014 1 次提交
  13. 09 7月, 2014 1 次提交
  14. 26 5月, 2014 1 次提交
  15. 04 5月, 2014 1 次提交
  16. 08 2月, 2014 1 次提交
    • P
      staging: android: sync: Signal pt before sync_timeline object gets destroyed · ac5b705b
      Prakash Kamliya 提交于
      There is a race condition
      
      Assume we have *one* sync_fence object, with *one* sync_pt
      which belongs to *one* sync_timeline, given this condition,
      sync_timeline->kref will have two counts, one for sync_timeline
      (implicit) and another for sync_pt.
      
      Assume following is the situation on CPU
      
      Theead-1 : (Thread which calls sync_timeline_destroy())
        -> (some function calls)
         -> sync_timeline_destory()
          -> sync_timeline_signal() (CPU is inside this
      function after putting reference to sync_timeline)
      
      At this time Thread-2 comes and does following
      
      Thread-2 : (fclose on fence fd)
      > sync_fence_release() -> because of fclose() on fence object
       -> sync_fence_free()
        -> sync_pt_free()
         -> kref_put(&pt->parent->kref, sync_timeline_free);
          -> sync_timeline_free() (CPU is inside this because
      this time kref will be zero after _put)
      
      Thread-2 will free sync_timeline object before Thread-1
      has finished its work inside sync_timeline_signal.
      
      With this change we signals all sync_pt before putting
      reference to sync_timeline object.
      
      Cc: Colin Cross <ccross@android.com>
      Cc: Android Kernel Team <kernel-team@android.com>
      Signed-off-by: NPrakash Kamliya <pkamliya@codeaurora.org>
      [jstultz: minor commit subject tweak]
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ac5b705b