On Thu, Sep 08, 2016 at 07:45:36AM +1000, Dave Chinner wrote: > It's a semaphore, not a mutex. Semaphore locking is independent of > task context, the lock follows the object it protects, not the task > that took the lock. i.e. Lockdep is wrong to assume the "owner" of a > rw_sem will not change between lock and unlock. That's not the case - rw_semaphores had strict owner semanics for a long time (although I wish we could get rid of that for a different reason..). The problem here is not that we have different tasks acquire and release the lock - it's always the same. The "problem" is that that we hand off work to a different task inbetween and that task asserts that the lock is held. With the old mrlock hack our islocked macros would return true as long as _someone_ holds the lock, while lockdep is generally more strict and wants the current process to hold the lock. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
