On Fri, 2013-03-01 at 01:42 -0500, Rik van Riel wrote: > On 02/28/2013 06:09 PM, Linus Torvalds wrote: > > > So I almost think that *everything* there in the semaphore code could > > be done under RCU. The actual spinlock doesn't seem to much matter, at > > least for semaphores. The semaphore values themselves seem to be > > protected by the atomic operations, but I might be wrong about that, I > > didn't even check. > > Checking try_atomic_semop and do_smart_update, it looks like neither > is using atomic operations. That part of the semaphore code would > still benefit from spinlocks. Agreed. > > The way the code handles a whole batch of semops all at once, > potentially to multiple semaphores at once, and with the ability > to undo all of the operations, it looks like the spinlock will > still need to be per block of semaphores. > > I guess the code may still benefit from Michel's locking code, > after the permission stuff has been moved from under the spinlock. How about splitting ipc_lock()/ipc_lock_control() in two calls: one to obtain the ipc object (rcu_read_lock + idr_find), which can be called when performing the permissions and security checks, and another to obtain the ipcp->lock [q_]spinlock when necessary. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|