On Wed, Nov 28, 2007 at 01:30:18PM +1100, Lachlan McIlroy wrote:
> We've fixed the source of the assertion (that was the bugs in
> xfs_buf_associate_memory()) so I'm pushing your buffer lock
> removal patch back in again.
> While looking through it I found a couple of issues:
> - It called unlock_page() before calls to PagePrivate() and
> PageUptodate(). I think the page needs to be locked during
> these calls so I moved the unlock_page() further down.
This doesn't really matter at all. XFS is the only user of the
address_space the pages reside in and we never have overlapping
buffers. That's the reason why we can remove the buffer locking.
Now if there was a variant of find_or_create_page that didn't set
pages locked at all we could happily use it and get rid of the last
place we deal with locked pages.
> - Unlocking the pages as we go can cause a double unlock in the
> error handling for a NULL page in the XBF_READ_AHEAD case so I
> removed the unlocking code for that case.
Indeed. Thanks for spotting this.