From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH] GFS2: Increase i_writecount during gfs2_setattr_size
Date: Wed, 29 May 2013 11:44:41 +0100 [thread overview]
Message-ID: <1369824281.2765.10.camel@menhir> (raw)
In-Reply-To: <2132542741.29815629.1369760061633.JavaMail.root@redhat.com>
Hi,
On Tue, 2013-05-28 at 12:54 -0400, Bob Peterson wrote:
> ----- Original Message -----
> | > --- a/fs/gfs2/rgrp.c
> | > +++ b/fs/gfs2/rgrp.c
> | > @@ -638,8 +638,10 @@ void gfs2_rs_deltree(struct gfs2_blkreserv *rs)
> | > */
> | > void gfs2_rs_delete(struct gfs2_inode *ip)
> | > {
> | > + struct inode *inode = &ip->i_inode;
> | > +
> | > down_write(&ip->i_rw_mutex);
> | > - if (ip->i_res) {
> | > + if (ip->i_res && atomic_read(&inode->i_writecount) <= 1) {
> | > gfs2_rs_deltree(ip->i_res);
> | > BUG_ON(ip->i_res->rs_free);
> | > kmem_cache_free(gfs2_rsrv_cachep, ip->i_res);
> | >
> |
> | Are there any other callers of gfs2_rs_delete where it is no appropriate
> | to have this new test?
> |
> | I assume that the issue is that this writecount test needs to be under
> | the i_rw_mutex?
> |
> | Steve.
>
> Hi,
>
> Nope. It's okay for reservations to go in and out of a rgrp reservations tree;
> it happens all the time. What we really need to protect is where it's
> freed from cache (kmem_cache_free) which only happens in function
> gfs2_rs_deltree, where it's now protected by this patch. And yes, it
> needs to be done under the i_rw_mutex.
>
Ok, sounds good. I've applied the patch to the -nmw tree.
> The bigger question is whether there are other places besides functions
> gfs2_setattr_size and gfs2_page_mkwrite that should be calling
> get_write_access to ensure this protection. These are the only two
> we've seen in actual practice, and I wanted the patch to be as
> minimal as possible.
>
> Regards,
>
> Bob Peterson
> Red Hat File Systems
Yes, looks good. If there are other places, they are likely to be those
where we write to internal files via an interface other than the vfs.
The quotactl interface comes to mind, and perhaps also statfs too. From
userspace, if we have an open file descriptor, then there should
generally not be a problem,
Steve.
prev parent reply other threads:[~2013-05-29 10:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2055011372.29570526.1369749816847.JavaMail.root@redhat.com>
2013-05-28 14:04 ` [Cluster-devel] [GFS2 PATCH] GFS2: Increase i_writecount during gfs2_setattr_size Bob Peterson
2013-05-28 14:20 ` Steven Whitehouse
2013-05-28 16:54 ` Bob Peterson
2013-05-29 10:44 ` Steven Whitehouse [this message]
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=1369824281.2765.10.camel@menhir \
--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).