RE: [RFC] rdma/uverbs: Sketch for an ioctl framework

Hefty, Sean
2016-05-27T00:22:56Z

> I'd say that is actually more likely to happen if it is open
> coded. Nested object locking like that requires consistent ordering to
> avoid deadlock..
>
> It would be easier for the core code to enforce consistent nested lock
> acquire ordering than to try and do that scattered across all the
> code. You are right, the core code cannot just iterate over the
> provided object list and grab the locks.
>
> One very simple option is for the core to enforce a sort order on the
> object list as it grabs the locks and fail&unwind for unordered lists.

I did not have object locking in my proposal. I tried to maintain very simple locking, hoping it would make it possible for a mere human to validate that the locking was correct. Plus it kept the size of the object structure smaller.

A lock associated with the idr is held while objects are acquired. A simple reference count is bumped for each object when used. If exclusive access is required, a flag is set. If the exclusive flag is set, then any attempt to acquire the object is rejected and the ioctl fails.

Coordination with the removal of the kernel client (i.e. device) is done using a rw-lock. Ioctls acquire a read lock, while the removal processing acquires the write lock.

Maybe there's a reason to create a more complex scheme than this, similar to what uverbs has, but AFAICT, this level of synchronization seems sufficient. Any lower-level locking is the responsibility of the kernel client.

- Sean