| 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 |
| Previous by Date: | Re: [BUG REPORT] missing memory counter introduced by xfs, Dave Chinner |
|---|---|
| Next by Date: | Re: [PATCH] xfs/279: filter scsi debug device correctly, Dave Chinner |
| Previous by Thread: | Re: [PATCH, RFC] xfs: remove i_iolock and use i_rwsem in the VFS inode instead, Christoph Hellwig |
| Next by Thread: | Re: [PATCH, RFC] xfs: remove i_iolock and use i_rwsem in the VFS inode instead, Peter Zijlstra |
| Indexes: | [Date] [Thread] [Top] [All Lists] |