From: kdasu <kdasu.kdev@gmail.com>
To: xfs@oss.sgi.com
Subject: Inode lockdep problem observed on 2.6.37.6 xfs with RT subvolume
Date: Wed, 1 Feb 2012 17:02:35 -0800 (PST) [thread overview]
Message-ID: <33246061.post@talk.nabble.com> (raw)
Need some help understanding the state of xfs with rt subvolume
support on 2.6.37.
When using xfs rt subvolume on a harddisk partition with kernel
2.6.37.6,and normal r/w/delete file operations causes deadlock
like hangs . Failure symptoms are lockups and mount failure on reboot.
On further investigation it was found that one of the changes could be
the cause.
The same tests seem to pass with xfs in 2.6.31 kernel.
xfs: simplify xfs_trans_iget :
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=aa72a5cf00001d0b952c7c755be404b9118ceb2e
aa72a5cf00001d0b952c7c755be404b9118ceb2e
Reverting the change and forward porting to the xfs_trans_iget() seems to
get rid of the deadlock and mount issues .
Below is the change
Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com>
---
linux-2.6.37/fs/xfs/xfs_trans_inode.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/linux-2.6.37/fs/xfs/xfs_trans_inode.c
b/linux-2.6.37/fs/xfs/xfs_trans_inode.c
index ccb3453..c2861d5 100644
--- a/stblinux-2.6.37/fs/xfs/xfs_trans_inode.c
+++ b/stblinux-2.6.37/fs/xfs/xfs_trans_inode.c
@@ -56,6 +56,27 @@ xfs_trans_iget(
xfs_inode_t **ipp)
{
int error;
+ xfs_inode_t *ip = NULL;
+ xfs_perag_t *pag = NULL;
+
+ /*
+ * If we find the inode in core with this transaction
+ * pointer in its i_transp field, then we know we already
+ * have it locked.
+ */
+ if(tp != NULL) {
+ pag = xfs_perag_get(mp, XFS_INO_TO_AGNO(mp, ino));
+ read_lock(&pag->pag_ici_lock);
+ ip = radix_tree_lookup(&pag->pag_ici_root,
XFS_INO_TO_AGNO(mp, ino));
+ read_unlock(&pag->pag_ici_lock);
+ xfs_perag_put(pag);
+ }
+
+ /* the returned inode must match the transaction */
+ if (ip && (ip->i_transp == tp)) {
+ *ipp = ip;
+ return 0;
+ }
error = xfs_iget(mp, tp, ino, flags, lock_flags, ipp);
if (!error && tp) {
--
1.7.6
I have also attached the xfs_logprint text output when the mount fails.
http://old.nabble.com/file/p33246061/xfslog-2.6.37.6-mount-fail.txt
xfslog-2.6.37.6-mount-fail.txt
Regards
Kamal
--
View this message in context: http://old.nabble.com/Inode-lockdep-problem-observed-on-2.6.37.6-xfs-with-RT-subvolume-tp33246061p33246061.html
Sent from the Xfs - General mailing list archive at Nabble.com.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2012-02-02 1:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-02 1:02 kdasu [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-02-02 0:44 Inode lockdep problem observed on 2.6.37.6 xfs with RT subvolume Kamal Dasu
2012-02-02 9:13 ` Christoph Hellwig
2012-02-02 16:26 ` Kamal Dasu
2012-02-02 16:28 ` Christoph Hellwig
2012-02-10 3:27 ` kdasu
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=33246061.post@talk.nabble.com \
--to=kdasu.kdev@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox