xfs
[Top] [All Lists]

Re: [PATCH] xfs: reset the i_iolock lock class in the reclaim path

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>