From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] Fix freeze of cluster-2.03.11
Date: Mon, 20 Apr 2009 14:33:14 +0100 [thread overview]
Message-ID: <1240234394.29604.77.camel@localhost.localdomain> (raw)
In-Reply-To: <1240233285.7900.271.camel@cerberus.int.fabbione.net>
Hi,
On Mon, 2009-04-20 at 15:14 +0200, Fabio M. Di Nitto wrote:
> Hi,
>
> On Mon, 2009-04-20 at 14:27 +0200, Kadlecsik Jozsef wrote:
> > Hi,
> >
> > I reported on the linux-cluster mailing list (see thread
> > https://www.redhat.com/archives/linux-cluster/2009-March/msg00176.html)
> > that version cluster-2.03.11 freezes.
> >
> > As Wendy Cheng pointed out, the reason for this is that the filesystem API
> > of the kernel changed and "put_inode" was replaced by "drop_inode": while
> > "put_inode" was called without holding any lock, "drop_inode" is called
> > under inode_lock held but the called gfs_sync_page_i may block
> > (https://www.redhat.com/archives/linux-cluster/2009-April/msg00060.html).
> >
Its not a replacement as such, they are different operations.
->put_inode() was called on each and every iput() (despite what the docs
said, as Christoph noted) whereas ->drop_inode() is only called when the
inode is being removed from the cache.
The purpose of drop inode is to allow the fs to override the decision
about whether the inode needs to be dallocated (->delete_inode()) or not
(->clear_inode()).
Christoph's patch is here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=33dcdac2df54e66c447ae03f58c95c7251aa5649
>
> > The patch below (applied in gfs-kernel/src/gfs/) fixes the bug by
> > releasing the lock before calling gfs_sync_page_i and locking it back
> > after the function call:
> >
> > --- gfs-orig/ops_super.c 2009-01-22 13:33:51.000000000 +0100
> > +++ gfs/ops_super.c 2009-04-06 13:07:06.000000000 +0200
> > @@ -9,6 +9,7 @@
> > #include <linux/statfs.h>
> > #include <linux/seq_file.h>
> > #include <linux/mount.h>
> > +#include <linux/writeback.h>
> >
> > #include "gfs.h"
> > #include "dio.h"
> > @@ -68,8 +69,11 @@
> > if (ip &&
> > !inode->i_nlink &&
> > S_ISREG(inode->i_mode) &&
> > - !sdp->sd_args.ar_localcaching)
> > + !sdp->sd_args.ar_localcaching) {
> > + spin_unlock(&inode_lock);
> > gfs_sync_page_i(inode, DIO_START | DIO_WAIT);
> > + spin_lock(&inode_lock);
> > + }
> > generic_drop_inode(inode);
> > }
> >
You can't do this in this particular way because you must set the
inode's state before releasing the inode_lock. That is done in
generic_drop_inode() and the functions that it calls.
Not to mention which, this doesn't seem to make any sense. It appears to
be trying to write the inode's data back to disk, but if we've got to
this point in the inode's life cycle, there should be nothing to write.
Since its only called when i_nlink is 0, thats even more strange since
(a) it could be moved to ->delete_inode() and (b) why do we care about
forcing out dirty data for an inode thats being unlinked anyway....
This patch raises more questions than it answers I think.
>
> >
> > Additionally, the line
> >
> > EXPORT_SYMBOL(inode_lock);
> >
> > must be added to fs/inode.c in order to the inode_lock symbol get
> > exported.
>
> thanks a lot for you effort but we will need to find another solution.
>
> it's been a long time since gfs1 required extra exported symbols from
> the kernel and asking distributions to do that again is not really an
> option (not sure if there any other option either).
>
> I'll let the gfs guys look at it.
>
> Thanks again!
> Fabio
>
Yes, we can't have any of our own exports now (since gfs isn't in the
upstream kernel), as per the ruling from the Fedora people,
Steve.
next prev parent reply other threads:[~2009-04-20 13:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-20 12:27 [Cluster-devel] [PATCH] Fix freeze of cluster-2.03.11 Kadlecsik Jozsef
2009-04-20 13:14 ` Fabio M. Di Nitto
2009-04-20 13:33 ` Steven Whitehouse [this message]
2009-04-20 16:36 ` Kadlecsik Jozsef
2009-04-21 8:39 ` Steven Whitehouse
2009-04-22 11:55 ` Kadlecsik Jozsef
2009-04-22 11:59 ` Steven Whitehouse
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=1240234394.29604.77.camel@localhost.localdomain \
--to=swhiteho@redhat.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;
as well as URLs for NNTP newsgroup(s).