xfs
[Top] [All Lists]

Re: [PATCH, RFC] xfs: remove i_iolock and use i_rwsem in the VFS inode i

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH, RFC] xfs: remove i_iolock and use i_rwsem in the VFS inode instead
From: Christoph Hellwig <hch@xxxxxx>
Date: Fri, 9 Sep 2016 10:33:06 +0200
Cc: Christoph Hellwig <hch@xxxxxx>, xfs@xxxxxxxxxxx, peterz@xxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160907214536.GQ30056@dastard>
References: <1470935423-12329-1-git-send-email-hch@xxxxxx> <20160811234335.GX16044@dastard> <20160812025026.GA975@xxxxxx> <20160812095813.GZ16044@dastard> <20160905151529.GB16726@xxxxxx> <20160907214536.GQ30056@dastard>
User-agent: Mutt/1.5.17 (2007-11-01)
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.

<Prev in Thread] Current Thread [Next in Thread>