sync: dump sync state to console on timeout

Change-Id: I74bca6b4a2afa7ed5b1f5233c5165d2edddf269a
Signed-off-by: Erik Gilling <konkers@android.com>
sync: use correct signed type when handling SYNC_IOC_WAIT

Change-Id: Ic7d5adf9b145765e52b23186b8c3c793ccf29be7
Signed-off-by: Erik Gilling <konkers@android.com>
sync: improve timeout dumps

Change-Id: I3b378d63c324c7b5862dd214f380b5e91131cc2a
Signed-off-by: Erik Gilling <konkers@android.com>
sync: dump sync state of fence errors

Change-Id: I297a43aadf83504993040ea875c7f22d988628f1
Signed-off-by: Erik Gilling <konkers@android.com>
sync: protect unlocked access to fence status

Fence status is checked outside of locks in both sync_fence_wait and
sync_fence_poll.  This patch adds propper barrier protection in these
cases to avoid seeing stale status.

Change-Id: I9d8b6ce6accb415e797df58068a1ccd54e6be445
Signed-off-by: Erik Gilling <konkers@android.com>
sync: update new fence status with sync_fence_signal_pt

If a fence's pt is signaled before sync_fence_create is called, the fence
will never transition into the signaled state.  This also address a tiny
race if a merged fence's pt after sync_fence_get_status checks it's status
and before fence->status is updated.

Change-Id: Ic8e292a323db26c6f04cb4757d920278b3125ff6
Signed-off-by: Erik Gilling <konkers@android.com>
sync: use proper barriers when waiting indefinitely

The previous fix only addressed waiting with a timeout.

Change-Id: I8ad735d2d0dfdd53592904e8a54f5689cb5eaa5e
Signed-off-by: Erik Gilling <konkers@android.com>
sync: refactor sync debug printing

Move driver callbacks to fill strings instead of using seq_files.  This
will allow those values to be used in a future tracepoint patch.

Change-Id: I9b706343e35b11124141fe520e520514a32003d2
Signed-off-by: Erik Gilling <konkers@android.com>
sw_sync: convert to new value_str debug ops

Change-Id: I9bad0cac1198043e04637641feb8112e2e7a9d11
Signed-off-by: Erik Gilling <konkers@android.com>
sync: add tracepoint support

Change-Id: I181326db4247009161557e45444c9b3548b83d25
Signed-off-by: Erik Gilling <konkers@android.com>
sync: add Documentation/sync.txt

Change-Id: Ic7f3a6d4622083be607b82ddd8d676609225bb8f
Signed-off-by: Erik Gilling <konkers@android.com>
sync: Fix race condition between merge and signal

The copied sync_pt was activated immediately. If the sync_pt was
signaled before the entire merge was completed, the new fence's pt_list
could be iterated over while it is still in the process of being
created.

Moving the the sync_pt_activate call for all new sync_pts to after both
the sync_fence_copy_pts and the sync_fence_merge_pts calls ensure that
the pt_list is complete and immutable before it can be reached from the
timeline's active list.

Signed-off-by: Erik Gilling <konkers@android.com>
sync: don't log wait timeouts when timeout = 0

Signed-off-by: Erik Gilling <konkers@android.com>
sync: fix timeout = 0 wait behavior

Change-Id: I8b9254e92c26d9f44abbc0c77fb44624de947013
Signed-off-by: Jamie Gennis <jgennis@google.com>
sync: signal pt before sync_timeline object gets destroyed

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.

Change-Id: Ic680e4d0bbef1c46bcb7cfba693395645241d203
Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
Signed-off-by: Rom Lemarchand <romlem@google.com>
sync: Fix a race condition between release_obj and print_obj

Before this change, a timeline would only be removed from the timeline
list *after* the sync driver had its release_obj() called. However, the
driver's release_obj() may free resources needed by print_obj().

Although the timeline list is locked when print_obj() is called, it is
not locked when release_obj() is called. If one CPU was in print_obj()
when another was in release_obj(), the print_obj() may make unsafe
accesses.

It is not actually necessary to hold the timeline list lock when calling
release_obj() if the call is made after the timeline is unlinked from
the list, since there is no possibility another thread could be in --
or enter -- print_obj() for that timeline.

This change moves the release_obj() call to after the timeline is
unlinked, preventing the above race from occurring.

Signed-off-by: Alistair Strachan <alistair.strachan@imgtec.com>