| To: | Alex Elder <aelder@xxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] xfs: reset the i_iolock lock class in the reclaim path |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Tue, 3 Nov 2009 09:55:59 -0500 |
| Cc: | Christoph Hellwig <hch@xxxxxxxxxxxxx>, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>, xfs@xxxxxxxxxxx |
| In-reply-to: | <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE5D@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
| References: | <20091019040526.GC21115@xxxxxxxxxxxxx> <1AB9A794DBDDF54A8A81BE2296F7BDFE83AE5D@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
| User-agent: | Mutt/1.5.19 (2009-01-05) |
On Mon, Nov 02, 2009 at 03:54:02PM -0600, Alex Elder wrote: > The comment in xfs_fs_clear_inode() is very informative, but > it may be emphasizing a lot of detail that doesn't really > help the reader at this spot in the code. What about wording > something more like this: > The iolock is used by the file system to coordinate > reads, writes, and block truncates. Up to this point > the lock protected concurrent accesses by users of > the inode. But from here forward we're doing some final > processing of the inode because we're done with it, > and although we reuse the iolock for protection it is > really a distinct lock class (in the lockdep sense) from > before. To keep lockdep happy (and basically indicate > what we are doing), we explicitly re-init the iolock here. Fine with me. Do you want a respin or will you fix up the comment on the fly? |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] xfs: fix mmap_sem vs iolock lock order inversion inxfs_free_eofblocks, Christoph Hellwig |
|---|---|
| Next by Date: | Leading Yemen Importers and Exporters, Yemen Business Directory |
| Previous by Thread: | RE: [PATCH] xfs: reset the i_iolock lock class in the reclaim path, Alex Elder |
| Next by Thread: | RE: [PATCH] xfs: use WRITE_SYNC_PLUG for synchronous writeout, Alex Elder |
| Indexes: | [Date] [Thread] [Top] [All Lists] |