public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 5/7] xfs: defer EFI and EFD log formatting until iop_format time
Date: Mon, 25 Nov 2013 19:50:49 +1100	[thread overview]
Message-ID: <20131125085049.GB8803@dastard> (raw)
In-Reply-To: <20131124091830.GA6253@infradead.org>

On Sun, Nov 24, 2013 at 01:18:30AM -0800, Christoph Hellwig wrote:
> On Sat, Nov 23, 2013 at 07:11:56AM -0800, Christoph Hellwig wrote:
> > No need to allocate large chunks of memory to format each extent into
> > an array when logging the EFI or EFD items.  Instead just point to the
> > bmap free list and only generate the log format at iop_format time.
> > 
> > Also get rid of the now almost empty xfs_trans_extfree.c by merging it
> > into xfs_extfree_item.c.
> > 
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Turns out this version can fairly easily cause use after frees, so it'll
> need a bit of an overhaul to get the lifetime rules right.

Yeah, you can't use the freelist structure like that - it's a
linked, which you copy the freelist structure when logging the
EFI/EFD, and then free the items on the linked list. Then when
formatting the structure, you walk the list attached to the copy of
the freelist structure, which has alreayd been freed.

Basically, we've got a bunch of nasty life cycle issues around the
EFI/EFD that need to be fixed. Firstly, the EFD code assumes that
the EFI always outlives it, but we don't take a reference when we
connect the EFD to the EFI - the EFI is created with the reference
for the EFD already added to it. Then in abort cases we simply free
the EFI, even though there may be an EFD that still references it...

So I think that this needs to be fixed up before you can even
consider sharing something like a reference counted freelist
structure between the EFI/EFD structures....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-11-25  8:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-23 15:11 [PATCH 0/7] decouple the in-memory from the on-disk log format Christoph Hellwig
2013-11-23 15:11 ` [PATCH 1/7] xfs: let iop_format write directly into the linear buffer Christoph Hellwig
2013-11-25  9:15   ` Dave Chinner
2013-11-25 13:37     ` Christoph Hellwig
2013-11-25 20:45       ` Dave Chinner
2013-11-26  6:02         ` Christoph Hellwig
2013-11-23 15:11 ` [PATCH 2/7] xfs: remove the inode log format from the inode log item Christoph Hellwig
2013-11-23 15:11 ` [PATCH 3/7] xfs: remove the dquot log format from the dquot " Christoph Hellwig
2013-11-23 15:11 ` [PATCH 4/7] xfs: remove the quotaoff log format from the quotaoff " Christoph Hellwig
2013-11-23 15:11 ` [PATCH 5/7] xfs: defer EFI and EFD log formatting until iop_format time Christoph Hellwig
2013-11-24  9:18   ` Christoph Hellwig
2013-11-25  8:50     ` Dave Chinner [this message]
2013-11-25 13:40       ` Christoph Hellwig
2013-11-23 15:11 ` [PATCH 6/7] xfs: remove efi_next_extent Christoph Hellwig
2013-11-23 15:11 ` [PATCH 7/7] xfs: remove opencoded versions of xfs_bmap_cancel Christoph Hellwig
2013-11-25  8:54 ` [PATCH 0/7] decouple the in-memory from the on-disk log format Dave Chinner
2013-11-25 13:35   ` Christoph Hellwig

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=20131125085049.GB8803@dastard \
    --to=david@fromorbit.com \
    --cc=hch@infradead.org \
    --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