linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: free uncommitted transactions during log recovery
Date: Mon, 12 Jun 2017 08:23:06 -0400	[thread overview]
Message-ID: <20170612122304.GA10244@bfoster.bfoster> (raw)
In-Reply-To: <20170610211029.GM4530@birch.djwong.org>

On Sat, Jun 10, 2017 at 02:10:29PM -0700, Darrick J. Wong wrote:
> On Fri, Jun 09, 2017 at 01:38:09PM -0400, Brian Foster wrote:
> > Log recovery allocates in-core transaction and member item data
> > structures on-demand as it processes the on-disk log. Transactions
> > are allocated on first encounter on-disk and stored in a hash table
> > structure where they are easily accessible for subsequent lookups.
> > Transaction items are also allocated on demand and are attached to
> > the associated transactions.
> > 
> > When a commit record is encountered in the log, the transaction is
> > committed to the fs and the in-core structures are freed. If a
> > filesystem crashes or shuts down before all in-core log buffers are
> > flushed to the log, however, not all transactions may have commit
> > records in the log. As expected, the modifications in such an
> > incomplete transaction are not replayed to the fs. The in-core data
> > structures for the partial transaction are never freed, however,
> > resulting in a memory leak.
> > 
> > Update xlog_do_recovery_pass() to walk the hash table of transaction
> > lists as the last step before it goes out of scope and free any
> > transactions that may remain on the lists. This prevents a memory
> > leak of partial transactions in the log.
> > 
> > Signed-off-by: Brian Foster <bfoster@redhat.com>
> 
> Looks ok, I think.
> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
> 
> Do the log intent items get freed properly too?  I /think/ the answer is
> yes, but that yes could use another set of eyes. :)
> 

Good question. Taking a quick look at the recovery lifecycle of an EFI,
we can see it is created in xlog_recover_efi_pass2() with 2 references.
This is called when we've hit a commit record for a transaction that
contains the on-disk EFI (so there's no potential leak before this
point). The first ref is immediately dropped after the EFI is inserted
into the AIL. The common expectation is that the other reference is
dropped when we process the commit record for the transaction that
contains the corresponding EFD (i.e., the case where the extent free
operation is captured by the log).

The alternative case (no EFD in the log) is the case where it is the
responsibility of the log recovery code to actually re-invoke the
operation. This occurs down in xlog_recover_process_intents() -> ... ->
xfs_efi_recover(), where we now allocate a corresponding EFD, perform
the free and commit the transaction. The EFD now owns the EFI, so at
this point I believe the same rules apply with respect to EFI/EFD memory
management as if log recovery weren't running. E.g., the modifications
eventually make it from the CIL to the on-disk log and ->iop_committed()
of the EFD drops the corresponding EFI reference and frees the EFD.

I think this will probably look the same for other intent types, so the
short of it is that I think the log intent items are not susceptible to
this problem. They are intentionally designed to handle the case where
the associated high-level transaction had not been completed by the time
the fs died. FWIW, if there was a problem here, I think the problem may
also be more obvious than a memory leak because the intent items sit in
the AIL and potentially pin the tail of the log.

Brian

> --D
> 
> > ---
> > 
> > FYI, I suspect this has been a problem for a while and and rare/harmless
> > enough that this can target 4.13.
> > 
> > Brian
> > 
> >  fs/xfs/xfs_log_recover.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
> > index 4a98762..37b34c5 100644
> > --- a/fs/xfs/xfs_log_recover.c
> > +++ b/fs/xfs/xfs_log_recover.c
> > @@ -5224,6 +5224,7 @@ xlog_do_recovery_pass(
> >  	int			error2 = 0;
> >  	int			bblks, split_bblks;
> >  	int			hblks, split_hblks, wrapped_hblks;
> > +	int			i;
> >  	struct hlist_head	rhash[XLOG_RHASH_SIZE];
> >  	LIST_HEAD		(buffer_list);
> >  
> > @@ -5466,6 +5467,19 @@ xlog_do_recovery_pass(
> >  	if (error && first_bad)
> >  		*first_bad = rhead_blk;
> >  
> > +	/*
> > +	 * Transactions are freed at commit time but transactions without commit
> > +	 * records on disk are never committed. Free any that may be left in the
> > +	 * hash table.
> > +	 */
> > +	for (i = 0; i < XLOG_RHASH_SIZE; i++) {
> > +		struct hlist_node	*tmp;
> > +		struct xlog_recover	*trans;
> > +
> > +		hlist_for_each_entry_safe(trans, tmp, &rhash[i], r_list)
> > +			xlog_recover_free_trans(trans);
> > +	}
> > +
> >  	return error ? error : error2;
> >  }
> >  
> > -- 
> > 2.7.5
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-06-12 12:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-09 17:38 [PATCH] xfs: free uncommitted transactions during log recovery Brian Foster
2017-06-09 19:36 ` Bill O'Donnell
2017-06-10 21:10 ` Darrick J. Wong
2017-06-12 12:23   ` Brian Foster [this message]
2017-06-15 17:07 ` Darrick J. Wong
2017-06-15 17:38   ` Brian Foster
2017-06-16 11:51   ` Brian Foster

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=20170612122304.GA10244@bfoster.bfoster \
    --to=bfoster@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    /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).