base: genlock: Properly destroy handle resources

The resources allocated for a handle were not being freed on device
release.  This included releasing the lock.  Unfortunately, the
lock release had a fput() too many which was screwing up the
reference counting on the file descriptors.  When attaching a lock,
we only need the file pointer for a short time so fput() it back
immediately.  That way, only there will only be one reference to
the lock per process, and the process will be responsible for
closing the fd directly and the fput() in genlock_release_lock
is no longer needed.

CRs-fixed: 322645
Change-Id: Ic0dedbad55300a2f8463c800cf8361719583b0b8
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
base: genlock: Avoid a race condition when releasing locks

Avoid a race condition if a lock gets released by all owners
but a process fails to close a lock file descriptor and tries
to reuse it.  Clearing the pointers to the data will ensure
that attaching a dead lock will return an error.

Change-Id: Ic0dedbadd693c7a22b027052cdd247370b28a7c5
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
base: genlock: Add error messages for failure cases

Signed-off-by: Naomi Luis <nluis@codeaurora.org>
Change-Id: I833e480abfc11ce4aa00a5ae46144895429a0339
base: genlock: Check for instances where handle is NULL

Check for the possibility of NULL handles passed into the
in-kernel API functions and return error where appropriate.
There is a non-zero chance that the private_data will be
cleared while the FD is still active, so check in the ioctl()
function as well.

CRs-fixed: 332835
Change-Id: Ic0dedbada2713080fef79ca188a87c578bec6d2f
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
base: genlock: Remove genlock_release_lock and associated ioctl

Allowing a lock to be asynchronously released while a handle
was still active turned out to be too dangerous to use in a
multi-threaded environment and it served no pratical
purpose anyway.  Handles now hold an attached lock until they
are destroyed.

CRs-fixed: 333141
Change-Id: Ic0dedbad8050ff01927ddb165c65a939bf297c10
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
base: genlock: allow synchronization with a single gralloc handle

In order to support synchronization in a process with a single
gralloc handle we require the ability to write lock a buffer
while it is already read locked by the same handle. This change
extends the concept of an exclusive write lock or recursive read
locks to a genlock handle (rather than the genlock lock).
Genlock cannot provide deadlock protection because the same
handle can be used simultaneously by a producer and consumer.
In practice an error will still be generated when the timeout
expires.

CRs-fixed: 356263
Change-Id: I322e7fadc8b43287f53b211242b176d3de731db2
Signed-off-by: Jeff Boody <jboody@codeaurora.org>
base: genlock: protect kref counting with spinlock

A race condition exists where the attach may not kref_get
before the kref_put finished. The genlock_file_lock was
originally added to protect against this case however it
was not protecting the kref.

CRs-fixed: 359649
Change-Id: Iab1fc847c2d3357ec1be79b7cc3e004643126dec
Signed-off-by: Jeff Boody <jboody@codeaurora.org>
base: genlock: add magic to protect attach from non-genlock file

It is possible for user space to attempt to attach a valid fd that
does not correspond to a genlock file. This change adds a magic to
the kernel private data that is used for validation.

CRs-fixed: 359649
Change-Id: Idb16056ba0f89b7d519d501f5b1ce6d5d930ed70
Signed-off-by: Jeff Boody <jboody@codeaurora.org>
base: genlock: handle error while creating lock/handle inode

A lock/handle inode is required in order to successfully create a
new lock/handle. Failure to report the lock/handle inode error can
result in errors for subsequent function calls.

Change-Id: I622af24e695f4781c4dbf46363931a7da09df677
Signed-off-by: Jeff Boody <jboody@codeaurora.org>