All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements
Date: Thu, 26 Jun 2008 23:02:04 +1000	[thread overview]
Message-ID: <20080626130204.GR29319@disturbed> (raw)
In-Reply-To: <20080626124009.GY4392@parisc-linux.org>

On Thu, Jun 26, 2008 at 06:40:09AM -0600, Matthew Wilcox wrote:
> On Thu, Jun 26, 2008 at 10:21:12PM +1000, Dave Chinner wrote:
> > On Thu, Jun 26, 2008 at 05:42:42AM -0600, Matthew Wilcox wrote:
> > > Then let's leave it as a semaphore.  You can get rid of the sema_t if
> > > you like, but I don't think that turning completions into semaphores is
> > > a good idea (because it's confusing).
> > 
> > So remind me what the point of the semaphore removal tree is again?
> 
> To remove the semaphores which don't need to be semaphores any more.

Or shouldn't be semaphores in the first place?

> > As Christoph suggested, I can put this under another API that
> > is implemented using completions. If I have to do that in XFS,
> > so be it....
> 
> You could, yes.  But you could just use completions directly ...

Not that I can see.

> > The main reason for this that we've just uncovered the fact that the
> > way XFS uses semaphores is completely unsafe [*] on x86/x86_64 for
> > kernels prior to the new generic semaphores.
> > 
> > [*] 2.6.20 panics in up() because of this race when I/O completion
> > (the up call) races with a simultaneous down() (iowaiter):
> > 
> > 	T1		T2
> > 	up()		down()
> > 			kmem_free()
> > 
> > When the down() call completes, the up() call can still be
> > referencing the semaphore, and hence if we free the structure after
> > the down call then the up() will reference freed memory.  This is
> > probably the cause of many unexplained log replay or unmount panics
> > that we've been hitting for years with buffers that been freed while
> > apparently still in use....
> 
> This is exactly the kind of thing completions were supposed to be used
> for.  T1 should be calling complete() and T2 should be calling
> wait_for_completion().

Yes, certainly. But as should be obvious by now completions don't
quite fit the bill for XFS - they only work for *synchronisation*
after the I/O. XFS needs *exclusion* during the I/O as well as
*synchronisation* after the I/O. The completion extensions provided the
exclusion part of the deal. How else do you suggest I implement
this?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2008-06-26 13:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-26  4:41 [PATCH 0/6] Remove most users of semaphores from XFS Dave Chinner
2008-06-26  4:41 ` [PATCH 1/6] Extend completions to provide XFS object flush requirements Dave Chinner
2008-06-26  7:46   ` Christoph Hellwig
2008-06-26 11:21     ` Dave Chinner
2008-06-26 13:07       ` Christoph Hellwig
2008-06-26 13:18         ` Dave Chinner
2008-06-26 11:26   ` Matthew Wilcox
2008-06-26 11:32     ` Dave Chinner
2008-06-26 11:42       ` Matthew Wilcox
2008-06-26 12:21         ` Dave Chinner
2008-06-26 12:40           ` Matthew Wilcox
2008-06-26 12:49             ` Christoph Hellwig
2008-06-26 13:02             ` Dave Chinner [this message]
2008-06-26 20:33   ` Daniel Walker
2008-06-27  1:52     ` Dave Chinner
2008-06-27  2:24     ` Matthew Wilcox
2008-06-27  3:26       ` Daniel Walker
2008-06-27  9:15         ` Christoph Hellwig
2008-06-27 14:37           ` Daniel Walker
2008-06-26  4:41 ` [PATCH 2/6] Replace inode flush semaphore with a completion Dave Chinner
2008-06-27  2:30   ` Matthew Wilcox
2008-06-27  4:13     ` Dave Chinner
2008-06-26  4:41 ` [PATCH 3/6] Replace dquot " Dave Chinner
2008-06-26  4:41 ` [PATCH 4/6] Replace the XFS buf iodone " Dave Chinner
2008-06-26  7:41   ` Christoph Hellwig
2008-06-26  4:41 ` [PATCH 5/6] Remove the sema_t from XFS Dave Chinner
2008-06-26  4:41 ` [PATCH 6/6] Clean up stale references to semaphores Dave Chinner
2008-06-26  7:47   ` 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=20080626130204.GR29319@disturbed \
    --to=david@fromorbit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.