cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] GFS2: Fix slab memory leak in gfs2_bufdata
Date: Fri, 13 Dec 2013 16:01:24 +0000	[thread overview]
Message-ID: <1386950484.2706.31.camel@menhir> (raw)
In-Reply-To: <1520497347.41496238.1386941465998.JavaMail.root@redhat.com>

Hi,

Thats a good bit of detective work. I've added it to the -nmw tree.
Thanks,

Steve.

On Fri, 2013-12-13 at 08:31 -0500, Bob Peterson wrote:
> Hi,
> 
> This patch fixes a slab memory leak that sometimes can occur
> for files with a very short lifespan. The problem occurs when
> a dinode is deleted before it has gotten to the journal properly.
> In the leak scenario, the bd object is pinned for journal
> committment (queued to the metadata buffers queue: sd_log_le_buf)
> but is subsequently unpinned and dequeued before it finds its way
> to the ail or the revoke queue. In this rare circumstance, the bd
> object needs to be freed from slab memory, or it is forgotten.
> We have to be very careful how we do it, though, because
> multiple processes can call gfs2_remove_from_journal. In order to
> avoid double-frees, only the process that does the unpinning is
> allowed to free the bd.
> 
> Regards,
> 
> Bob Peterson
> Red Hat File Systems
> 
> Signed-off-by: Bob Peterson <rpeterso@redhat.com> 
> ---
> diff --git a/fs/gfs2/meta_io.c b/fs/gfs2/meta_io.c
> index e57f608..c7f2469 100644
> --- a/fs/gfs2/meta_io.c
> +++ b/fs/gfs2/meta_io.c
> @@ -261,6 +261,7 @@ void gfs2_remove_from_journal(struct buffer_head *bh, struct gfs2_trans *tr, int
>  	struct address_space *mapping = bh->b_page->mapping;
>  	struct gfs2_sbd *sdp = gfs2_mapping2sbd(mapping);
>  	struct gfs2_bufdata *bd = bh->b_private;
> +	int was_pinned = 0;
>  
>  	if (test_clear_buffer_pinned(bh)) {
>  		trace_gfs2_pin(bd, 0);
> @@ -276,12 +277,16 @@ void gfs2_remove_from_journal(struct buffer_head *bh, struct gfs2_trans *tr, int
>  			tr->tr_num_databuf_rm++;
>  		}
>  		tr->tr_touched = 1;
> +		was_pinned = 1;
>  		brelse(bh);
>  	}
>  	if (bd) {
>  		spin_lock(&sdp->sd_ail_lock);
>  		if (bd->bd_tr) {
>  			gfs2_trans_add_revoke(sdp, bd);
> +		} else if (was_pinned) {
> +			bh->b_private = NULL;
> +			kmem_cache_free(gfs2_bufdata_cachep, bd);
>  		}
>  		spin_unlock(&sdp->sd_ail_lock);
>  	}
> 




      reply	other threads:[~2013-12-13 16:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <780452635.41494008.1386941225511.JavaMail.root@redhat.com>
2013-12-13 13:31 ` [Cluster-devel] GFS2: Fix slab memory leak in gfs2_bufdata Bob Peterson
2013-12-13 16:01   ` 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=1386950484.2706.31.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).