All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Tinguely <tinguely@sgi.com>
To: Sage Weil <sage@inktank.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	sage@newdream.net, xfs@oss.sgi.com
Subject: Re: [PATCH 0/5] do not take the iolock in inode reclaim context
Date: Tue, 17 Jul 2012 12:27:21 -0500	[thread overview]
Message-ID: <5005A079.4010007@sgi.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1207170845060.30672@cobra.newdream.net>

On 07/17/12 10:46, Sage Weil wrote:
> On Tue, 17 Jul 2012, Christoph Hellwig wrote:
>> ping/  I'd really like to get this queued up for 3.6
>
> I forget if I mentioned this before, but I pulled this series into our
> testing branch and have had no problems (aside from the last patch not
> applying to my tree) in qa (ceph on xfs) over the last couple of weeks.
>
> sage

Sage,

The patch "5-5-xfs-remove-iolock-lock-classes.patch" does not cleanly
apply because the comment that the patch is trying to remove in
xfs_iget.c has the following character sequence "<D1><95>" that the
mailer converted to a "?". It is easy enough to hand patch:


/*
  * Define xfs inode iolock lockdep classes. We need to ensure that all 
active
  * inodes are considered the same for lockdep purposes, including 
inodes that
  * are recycled through the XFS_IRECLAIMABLE state. This is the the 
only way to
  * guarantee the locks are considered the same when there are multiple lock
  * initialisation site<D1><95>. Also, define a reclaimable inode class 
so it is
                       ^^^^^^^^

--Mark Tinguely.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2012-07-17 17:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-04 15:13 [PATCH 0/5] do not take the iolock in inode reclaim context Christoph Hellwig
2012-07-04 15:13 ` [PATCH 1/5] xfs: clean up xfs_inactive Christoph Hellwig
2012-07-26 15:30   ` Rich Johnston
2012-07-04 15:13 ` [PATCH 2/5] xfs: remove xfs_inactive_attrs Christoph Hellwig
2012-07-26 15:31   ` Rich Johnston
2012-07-04 15:13 ` [PATCH 3/5] xfs: do not take the iolock in xfs_inactive Christoph Hellwig
2012-07-26 15:31   ` Rich Johnston
2012-07-04 15:13 ` [PATCH 4/5] xfs: avoid the iolock in xfs_free_eofblocks for evicted inodes Christoph Hellwig
2012-07-26 15:31   ` Rich Johnston
2012-07-04 15:13 ` [PATCH 5/5] xfs: remove iolock lock classes Christoph Hellwig
2012-07-26 15:31   ` Rich Johnston
2012-07-06  0:05 ` [PATCH 0/5] do not take the iolock in inode reclaim context Sage Weil
     [not found] ` <20120717071923.GD15473@infradead.org>
2012-07-17 15:46   ` Sage Weil
2012-07-17 17:27     ` Mark Tinguely [this message]
2012-07-26 15:30 ` Rich Johnston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5005A079.4010007@sgi.com \
    --to=tinguely@sgi.com \
    --cc=hch@infradead.org \
    --cc=sage@inktank.com \
    --cc=sage@newdream.net \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.