xfs
[Top] [All Lists]

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

To: Christoph Hellwig <hch@xxxxxx>
Subject: Re: [PATCH, RFC] xfs: remove i_iolock and use i_rwsem in the VFS inode instead
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 8 Sep 2016 07:45:36 +1000
Cc: xfs@xxxxxxxxxxx, peterz@xxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160905151529.GB16726@xxxxxx>
References: <1470935423-12329-1-git-send-email-hch@xxxxxx> <20160811234335.GX16044@dastard> <20160812025026.GA975@xxxxxx> <20160812095813.GZ16044@dastard> <20160905151529.GB16726@xxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Sep 05, 2016 at 05:15:29PM +0200, Christoph Hellwig wrote:
> Hi Dave,
> 
> I looked into killing the mrlock and ran into an unexpected problem.
> 
> Currently mr_writer tracks that there is someone holding a write lock,
> lockdep on the other hand checks if the calling thread has that lock.
> 
> While that generally is the right semantic, our hack to offload
> btree splits to a work item offends lockdep.  E.g. this callstack
> now asserts:

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.

> While it previously did fine.  I fear there might be other locking
> asserts in the code called from that work item as well.

Probably.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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